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!

Reply

Vivado 2017.3 add_files takes hours ...

Highlighted
Visitor rst
Visitor
Posts: 14
Registered: ‎05-25-2016

Vivado 2017.3 add_files takes hours ...

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)
...

 

Posts: 1,268
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

@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 star mark).
Visitor rst
Visitor
Posts: 14
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

[ Edited ]

@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?

Posts: 1,268
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

@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 star mark).
Explorer
Posts: 214
Registered: ‎04-26-2012

Re: Vivado 2017.3 add_files takes hours ...

[ Edited ]

@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

Visitor rst
Visitor
Posts: 14
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

@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).

Visitor rst
Visitor
Posts: 14
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

@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.

Posts: 1,268
Registered: ‎06-24-2015

Re: Vivado 2017.3 add_files takes hours ...

@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 star mark).
Visitor rst
Visitor
Posts: 14
Registered: ‎05-25-2016

Re: Vivado 2017.3 add_files takes hours ...

@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.

Explorer
Posts: 214
Registered: ‎04-26-2012

Re: Vivado 2017.3 add_files takes hours ...

@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