cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jake.freeman
Visitor
Visitor
1,406 Views
Registered: ‎02-14-2019

When opening a synthesized design in 2018.3, reading xpm_cdc_async_rst.tcl takes a long time

We recently upgraded from Vivado 2017.4 to 2018.3 and the time it takes to open a synthesized design has increased dramatically. The file it is getting stuck on is xpm_cdc_async_rst.tcl. Opening the file reveals a single line:

set_false_path -through [get_ports src_arst] to [all_registers]

The [all_registers] command seems suspect to me, like everytime this file is sourced the entire design is searched. 

Has anyone else run into this problem and has anyone found a work around?

0 Kudos
Reply
17 Replies
viviany
Xilinx Employee
Xilinx Employee
1,385 Views
Registered: ‎05-14-2008

Are you migrating a post-synthesis design to 2018.3 or an RTL based design?

Where is the XPM in your design? Are you using the XPM in your own RTL or is it in a Xilinx IP?

If it is an RTL based design and the XPM is in a Xilinx IP, please upgrade the IP to the 2018.3 version.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Reply
hemangd
Moderator
Moderator
1,373 Views
Registered: ‎03-16-2017

Hi @jake.freeman ,

Do not use all_registers for your constraints if you want to reduce runtime. 

all_registers command query all the cells connected to a particular clock/cell depends on your option which you used with it. The returned list can be very large while only a few objects need to be constrained. This can impact the runtime negatively.

Following is an example of timing exceptions that can negatively impact the runtime:
set_false_path -from [get_ports din] -to [all_registers] 

If the din port feeds only to sequential elements, there is no need to specify the false path to the sequential cells explicitly. This constraint can be written more efficiently:

set_false_path -from [get_ports din]

If the false path is needed, but only a few paths exist from the din port to any sequential cell in the design, then it can be more specific (all_registers can potentially return thousands of cells, depending upon the number of registers used in the design):

set_false_path -from [get_ports din] -to [get_cells blockA/config_reg[*]]

 

 

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Reply
jake.freeman
Visitor
Visitor
1,357 Views
Registered: ‎02-14-2019

Thanks for the quick responses. Here's some answers to your questions. 

Q. Are you migrating a post-synthesis design to 2018.3 or an RTL based design?

A. No, it's an RTL based design using many Xilinx IP in a block design.

Q. Where is the XPM in your design? Are you using the XPM in your own RTL or is it in a Xilinx IP?

A. In Xilinx IPs

Q. If it is an RTL based design and the XPM is in a Xilinx IP, please upgrade the IP to the 2018.3 version.

A. I have already upgraded all IPs to 2018.3

 

And regarding "Do not use all_registers for your constraints if you want to reduce runtime." I completely agree. I believe its Xilinx IP that are using the xpm, which is where the constraint is. 

Any thoughts? Thanks a lot. 

0 Kudos
Reply
viviany
Xilinx Employee
Xilinx Employee
1,337 Views
Registered: ‎05-14-2008

Which IP is it?

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Reply
jake.freeman
Visitor
Visitor
1,328 Views
Registered: ‎02-14-2019

@viviany,

Looking at the timing constraints window, I see it's referenced 176 total times by the following:

- AXI Interconnect 2.1
- AXI Clock Converter 2.1
- FIFO Generator 13.2

Thanks,
-Jake

0 Kudos
Reply
hemangd
Moderator
Moderator
1,313 Views
Registered: ‎03-16-2017

Hi @jake.freeman , 

Which OS version are you using for Vivado 2018.3? 

 

Is it possible to share your testcase to reproduce this issue at my end? If yes, i will send the ezmove ftp through which you can provide archived testcase. 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Reply
jake.freeman
Visitor
Visitor
1,308 Views
Registered: ‎02-14-2019

@hemangd,

We are using ubuntu 16.04 LTS. Unfortunately I cannot share the actual design, I'd have to create a generic test case using those IP.

Thanks a lot,
-Jake 

0 Kudos
Reply
hemangd
Moderator
Moderator
1,304 Views
Registered: ‎03-16-2017

Hi @jake.freeman , 

It will be helpful to debug this issue if you will provide a testcase/generic testcase where we can reproduce this issue at our end. 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Reply
viviany
Xilinx Employee
Xilinx Employee
1,274 Views
Registered: ‎05-14-2008

I see the problem in XPM with those IPs.

What is the runtime difference of opening synthesized design between 2017.4 and 2018.3?

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Reply
viviany
Xilinx Employee
Xilinx Employee
1,269 Views
Registered: ‎05-14-2008

Can you provide the log file in 2018.3 that can demonstrate the long runtime of opening synthesized design and the printed messages during this process?

Can you provide the post-synthesis DCP for use to reproduce the long runtime?

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Reply
jake.freeman
Visitor
Visitor
1,255 Views
Registered: ‎02-14-2019

@viviany Thanks for all your help. The time to open my synthesized design in 2017.4 was 12 minutes, and it jumped to ~25 minutes for 2018.3. 

0 Kudos
Reply
viviany
Xilinx Employee
Xilinx Employee
1,235 Views
Registered: ‎05-14-2008

In 2019.1, we have a better solution for you.

You can change the xpm_cdc_async_rst.tcl file in below folder.

....../Vivado/2019.1/data/ip/xpm/xpm_cdc/tcl/xpm_cdc_async_rst.tcl

Change 

"set_false_path -through [get_ports src_arst] -to [all_registers]"

to

"set_false_path -through [get_ports -no_traverse src_arst]"

 

2019.1 will be released soon.

However, in 2018.3 this solution is not available.

I suggest you move to 2019.1.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
jdehaven
Contributor
Contributor
1,098 Views
Registered: ‎05-27-2008

Vivian,

I'm the local Avnet FAE working with Jake on this issue.  Could you explain why the 2019.1 fix you suggested will not work in 2018.3?  Is the "-no_tranverse" option new to 2019.1?

It is too late in the development cycle for the customer to move to 2019.1.  What workarounds are available for 2018.3?

 

jd
0 Kudos
Reply
1,080 Views
Registered: ‎01-22-2015

@jdehaven 

As you know, only a small amount of code (HDL) is needed to create a circuit that is equivalent to the reset-synchronizer produced by the xpm_cdc_async_rst macro.  Does the customer not prefer this solution to a workaround for Vivado v2018.3?

Mark

0 Kudos
Reply
jake.freeman
Visitor
Visitor
1,067 Views
Registered: ‎02-14-2019

Mark,

The constraint created in the xpm_cdc_async_rst.tcl is file is used by Xilinx IP. I can see in the constraints window that it used by at least AXI width converters and AXI clock crossing IP. Is there a way to force these IP to use custom HDL rather than the Xilinx macro?

Thanks,

Jake  

0 Kudos
Reply
1,056 Views
Registered: ‎01-22-2015

@jake.freeman 

    Is there a way to force these IP to use custom HDL rather than the Xilinx macro?
I must defer to Xilinx and the FAE on that one - sorry.

Mark

0 Kudos
Reply
viviany
Xilinx Employee
Xilinx Employee
1,046 Views
Registered: ‎05-14-2008


@jdehaven wrote:

Vivian,

I'm the local Avnet FAE working with Jake on this issue.  Could you explain why the 2019.1 fix you suggested will not work in 2018.3?  Is the "-no_tranverse" option new to 2019.1?

It is too late in the development cycle for the customer to move to 2019.1.  What workarounds are available for 2018.3?

 


Yes, the -no_tranverse option is new to 2019.1.

In 2018.3, it will be not easy to resolve the issue.

Can the customer figure out which IP that is using the xpm_cdc_async_rst.tcl caused the long runtime?

If there is just one or two, we may be able to resolve it at the IP top level.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Reply