UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer rst
Observer
2,121 Views
Registered: ‎05-25-2016

Vivado 2017.3 add_files takes hours ...

Jump to solution

Hi,

 

after upgrading a Vivado 2016.2 design to Vivado 2017.3 (Red Hat Enterprise Linux Workstation release 6.6, 64 GByte RAM) the synthesis took about 3:30 h while it only took about 1:15 h in Vivado 2016.2. According to the synthesis log file this delay is caused by "add_files".

 

In Vivado 2017.3 the corresponding line is:

add_files: Time (s): cpu = 02:11:13 ; elapsed = 02:37:37 . Memory (MB): peak = 2437.496 ; gain = 1172.918 ; free physical = 10576 ; free virtual = 58009

In Vivado 2016.2 the corresponding line is:

add_files: Time (s): cpu = 00:00:19 ; elapsed = 00:00:25 . Memory (MB): peak = 1290.699 ; gain = 240.234 ; free physical = 14032 ; free virtual = 37777

 

Does anyone have an idea why this takes such a long time in Vivado 2017.3?

 

I don't know whether this is related to the problem, but I state it for completeness:

The top command shows that from time to time the srcscanner program becomes <defunct> during this lengthy add_files period. Trying to run the srcscanner command separately from the command line returned an error message about missing libraries:

 

./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ./srcscanner)
./srcscanner: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./srcscanner)
./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./srcscanner)
./srcscanner: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./srcscanner)
./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./srcscanner)
./srcscanner: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/lib/lnx64.o/libboost_filesystem.so)
./srcscanner: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/lib/lnx64.o/libboost_filesystem.so)
./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/lib/lnx64.o/libboost_filesystem.so)
./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/lib/lnx64.o/libboost_filesystem.so)
./srcscanner: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/lib/lnx64.o/libboost_regex.so)
...

 

0 Kudos
1 Solution

Accepted Solutions
Observer rst
Observer
2,246 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@brimdavis

 

Replacing all RTL modules by custom IP cores solved the problem.

 

By the way, the tcl command replace_bd_cell was very helpful for this task:

To replace all RTL modules (e.g. VLNV="xilinx.com:module_ref:sync_32:1.0") with their custom IP counterparts (e.g. VLNV="blub:blub_lib:sync_32:1.0") run the following TCL commands:

 

set toBeReplaced [get_bd_cells -hierarchical -filter {VLNV == "xilinx.com:module_ref:sync_32:1.0"}]
set numToBeReplaced [llength $toBeReplaced]

for {set i 0} {$i < $numToBeReplaced} {incr i} {
    set name [lindex $toBeReplaced $i]
    set tmpName ${name}_tmp    
    set oldName ${name}_old1
    create_bd_cell -type ip -vlnv blub:blub_lib:sync_32:1.0 $tmpName
    replace_bd_cell -preserve_name –preserve_configuration $name $tmpName
    delete_bd_objs [get_bd_cells $oldName]
}

 

 

 

13 Replies
Moderator
Moderator
2,099 Views
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst

 

Can you please share a testcase so that we can reproduce this issue at our end?

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
Observer rst
Observer
2,072 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@nupurs

 

Unfortunately I cannot provide you my current design so I have to trace down the problem to create a testcase. Is it possible to check which process causes this delay of "add_files"? As stated in my original post the srcscanner process behaves strangely. Is there a way to run this srcscanner separately on my sources to see how long this takes? Currently I'm able to start it from the command line via

/cae_appl/tools/xilinx/vivado2017.3/Vivado/2017.3/bin$
./loader -exec srcscanner
srcscan starts
%

but what to do next?

0 Kudos
Moderator
Moderator
2,067 Views
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst

 

Do you face a similar issue when you add_files in older version of Vivado and migrate the project to latest version?

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
Voyager
Voyager
2,055 Views
Registered: ‎04-26-2012

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst "According to the synthesis log file this delay is caused by "add_files"."

 

Have a look at AR 69846, which offers some advice on changing srcscanner settings to manual:

  AR 69846  2017.2 Vivado - The hierarchy source view in Vivado 2017.x is incorrect or takes a long time to update compared with Vivado 2016.x

  https://www.xilinx.com/support/answers/69846.html

  " Each time I add or update a source file, the Sources Tab displays an "Updating" status
  " and I have to wait several minutes for it to finish.  Looking at the system processes,
  " I see that srcscanner (.exe) is using a lot of the processor resources.
  <snip>
  " Most issues with slowness or incorrect file compile order being sent to synthesis
  " can be worked around by using one of the manual compile order settings. 

 

-Brian

0 Kudos
Observer rst
Observer
1,964 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@nupurs

 

I tried to iteratively increment the version starting with vivado 2016.2. The add_files problem starts with vivado 2017.1. By the way, in Vivado 2017.1 add_files "only" took about one hour instead of two hours (see my initial post).

0 Kudos
Observer rst
Observer
1,958 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@nupurs

 

I created a small test design where "add_files" still takes about 10 minutes. This is far too long as this test design is a massively reduced version of the original design where add_files only took 25 seconds in vivado 2016.2 (see my initial post).

 

To create the test project untar and chdir to directory "work". There run "make  icb_vivado_1". This should create the project icb_vivado_1.xpr in directory icb_vivado_1. Open it in Vivado 2017.3, right click on the block design in the "Hierarchy View" and set option "Global" in the "Generate Output Products ..." menu. Then run "Create HDL Wrapper". Finally run synthesis. On my machine the synthesis log file states:

 

add_files: Time (s): cpu = 00:09:15 ; elapsed = 00:10:50 . Memory (MB): peak = 1357.371 ; gain = 92.781 ; free physical = 2470 ; free virtual = 42381

 

It looks like the RTL modules (see hier_top/pcie_top/icb_register/icb_register_drx0) cause the problem. While creating the test project I noticed that a reduction in the number of RTL modules reduced the time required by add_files from initially 2:37:37 to 00:10:50.

0 Kudos
Moderator
Moderator
1,949 Views
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst

 

As brimdavis pointed out, can you check this AR: https://www.xilinx.com/support/answers/69846.html

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
Highlighted
Observer rst
Observer
1,943 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@nupurs

@brimdavis

 

I set "Hierarchy Source View" into operating mode "Automatic update, Manual Compile Order" (as proposed in AR# 69846):

set_property source_mgmt_mode DisplayOnly [current_project]

But according to the message returned by validating the block design, RTL modules are not supported in manual compile order:

[filemgmt 56-176] Module references are not supported in manual compile order mode and will be ignored.

Running synthesis fails with the message

Failed to resolve reference. Nothing was found in the project to match the name 'sync_32'.

Here 'sync32' is the name of an RTL module.

 

Our design has a lot of such RTL modules therefore this approach seems not to work.

0 Kudos
Voyager
Voyager
1,932 Views
Registered: ‎04-26-2012

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst "But according to the message returned by validating the block design, RTL modules are not supported in manual compile order:"

 

It appears that this error occurs during the Block Design phase, so I'd try something along these lines:

  - turn srcscanner on

  - generate BD output products

  - turn srcscanner off

  - run synthesis

 

-Brian

0 Kudos
Observer rst
Observer
958 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@brimdavis

 

Indeed, turning srcscanner on, running generate output products and turning srcscanner off, makes synthesis to work. But unfortunately add_files didn't become any faster (here the results for the test design):

 

add_files: Time (s): cpu = 00:09:14 ; elapsed = 00:11:38 . Memory (MB): peak = 1357.363 ; gain = 92.781 ; free physical = 480 ; free virtual = 40543

So, unfortunately, the approach of turning off srcscanner before running synthesis didn't help.

0 Kudos
Voyager
Voyager
943 Views
Registered: ‎04-26-2012

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@rst "So, unfortunately, the approach of turning off srcscanner before running synthesis didn't help."

 

Looking at this quickly tonight, it appears that the problem is not really synthesis per se, but that the Vivado synthesis tcl script first does an "add_files" of the associated project BD file (probably to extract the source dependency tree), and this add-of-the-block-diagram is what causes the huge srcscanner delay.

 

EDIT: This unresolved thread from August describes the same problem on Win7:

   https://forums.xilinx.com/t5/Synthesis/Vivado-2017-2-srcscanner-delays-synthesis-for-a-long-time/m-p/788036

 

Given that your RTL module references blow up when disabling srcscanner, that workaround appears to be off the table.

 

The only other suggestion I can think of, which would be painful the first time around, would be for you to manually write your own project synthesis script that does NOT do an add_files of the BD- i.e. you could probably extract the source dependencies in tcl (see get_files/report_compile_order/etc) and then modify the project.runs/synth_1/project.tcl script to remove the BD add. Getting all the sources/libraries/constraints straight in this will be a pain, I'm not sure if you can automate this fully in TCL, I've never tried.

 

-Brian

 

p.s.  I did once see an AR or release notes talking about Xilinx reducing the frequency of the srcscanner updates to prevent other problems with that root-of-all-evil srcscanner process, but I can't find it at the moment - i.e. there might be some obscure tcl flag(s) one can set that control srcscanner operation.

 

 

0 Kudos
Observer rst
Observer
2,247 Views
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

@brimdavis

 

Replacing all RTL modules by custom IP cores solved the problem.

 

By the way, the tcl command replace_bd_cell was very helpful for this task:

To replace all RTL modules (e.g. VLNV="xilinx.com:module_ref:sync_32:1.0") with their custom IP counterparts (e.g. VLNV="blub:blub_lib:sync_32:1.0") run the following TCL commands:

 

set toBeReplaced [get_bd_cells -hierarchical -filter {VLNV == "xilinx.com:module_ref:sync_32:1.0"}]
set numToBeReplaced [llength $toBeReplaced]

for {set i 0} {$i < $numToBeReplaced} {incr i} {
    set name [lindex $toBeReplaced $i]
    set tmpName ${name}_tmp    
    set oldName ${name}_old1
    create_bd_cell -type ip -vlnv blub:blub_lib:sync_32:1.0 $tmpName
    replace_bd_cell -preserve_name –preserve_configuration $name $tmpName
    delete_bd_objs [get_bd_cells $oldName]
}

 

 

 

755 Views
Registered: ‎01-16-2018

Re: Vivado 2017.3 add_files takes hours ...

Jump to solution

For anyone else who finds this thread, I recommend you jump over to https://forums.xilinx.com/t5/Synthesis/Vivado-2017-2-srcscanner-delays-synthesis-for-a-long-time/td-p/788036

 

TL;DR contact Xilinx support and they may be able to give you a temporary workaround to add_files (srcscanner) slowness.  In one project, the time dropped from 20 minutes to just 15 seconds without replacing anything with custom IP.  You should still engage with support to track down the root cause and fix it before your next Vivado upgrade.

0 Kudos