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: 
Contributor
Contributor
8,779 Views
Registered: ‎04-08-2009

Ignore combinatorial loop in timing

Jump to solution

Hi,

 

I have a design with a combinatorial loop which I'm aware of and I want to keep.

Alas, with this loop, my minimal clockperiod has increased with a factor of almost 8.

 

Is there any way I can ask ISE (and afterwards XPS) not to take in account this path

during timing analysis ?

I've looked into the timing constraint manual, but I can't seem to fix it :(

- With the FROM-TO-THRU statement can't point to the net to ignore

-  with the "False Paths by Net", I don't find the signal, which I wanna ignore, in the

   NET-dropbox.

 

Can anyone help me out ?

I'd appreciate it very much :-)

 

kr

jo

0 Kudos
1 Solution

Accepted Solutions
Scholar austin
Scholar
12,417 Views
Registered: ‎02-27-2008

Re: Ignore combinatorial loop in timing

Jump to solution

j,

 

The "from through to" constraints in my experience should only be used for the very tricky, and tough paths, and then only with no wildcards in the names.


The TIG "ignore" constraint is what I think you need here, and you should look at your VHDL/verilog and choose some net names that can be easily "ignored" by using a widldcard in the name.

 

The pull downs are a convenience which may not "find" what you are looking for (hard to read your mind with software), and you may need to actually look at the HDL to find the path name to ignore, and place it in the .ucf file manually.

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
7 Replies
Scholar austin
Scholar
12,418 Views
Registered: ‎02-27-2008

Re: Ignore combinatorial loop in timing

Jump to solution

j,

 

The "from through to" constraints in my experience should only be used for the very tricky, and tough paths, and then only with no wildcards in the names.


The TIG "ignore" constraint is what I think you need here, and you should look at your VHDL/verilog and choose some net names that can be easily "ignored" by using a widldcard in the name.

 

The pull downs are a convenience which may not "find" what you are looking for (hard to read your mind with software), and you may need to actually look at the HDL to find the path name to ignore, and place it in the .ucf file manually.

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Contributor
Contributor
8,753 Views
Registered: ‎04-08-2009

Re: Ignore combinatorial loop in timing

Jump to solution

Hi Austin,

 

I followed your advice ... and it worked :)

 

I added a "NET inst_componentX/TCouput*" TIG;" to my .ucf file and now the PAR-tool

successfully finishes off with the timing constraints I was aiming at.

 

Thanks a lot !

 

kr

jo 

0 Kudos
Scholar austin
Scholar
8,744 Views
Registered: ‎02-27-2008

Re: Ignore combinatorial loop in timing

Jump to solution

j,

 

Great!

 

I am so happy when something I wrote actually helps someone.  I hadly ever hear back when someone succeeds.

 

Thank you,

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Observer gyellen1120
Observer
4,904 Views
Registered: ‎10-28-2013

Re: Ignore combinatorial loop in timing

Jump to solution

I used this same approach in ISE to get it to ignore a deliberate combinatorial loop.

 

However, in Vivado, even though the comparable set_false_path seems to be parsed correctly, I am still getting a warning for the timing loop that goes through the named net:

 

I.e., even with this line in the XDC file:

set_false_path -through [get_nets * -hierarchical -filter {NAME =~ *prevYPeaksIn*}]

 

I still get this message during synthesis:

Found timing loop:

...

     3: \CHANL[0].i_Channeli_26 /prevYPeaksIn[1] (ChannelPLL__GBM4)

...

 

Any suggestions?

Thanks.

0 Kudos
Historian
Historian
4,896 Views
Registered: ‎01-23-2009

Re: Ignore combinatorial loop in timing

Jump to solution

Hmmm... This is an interesting one...

 

The set_false_path command disables checks on a timing path. The -through option is just part of the enumeration process which tells it which timing paths to disable.

 

However, a combinatorial loop is not a timing path - that's exactly why its a problem for the static timing analysis tools...

 

The only way I know to disable a combinatorial loop is through path segmentation - you need to do a set_max_delay with a -from that is not a startpoint, or a -to that is not an endpoint. This will segment the paths going through this point, including breaking the combinatorial loop.

 

However, I have to ask - are you sure you want to keep the combinatorial loop? These are generally very rare and quite dangerous (and impossible to constrain properly). There are very few situations where I would want to keep one...

 

Avrum

 

Tags (2)
0 Kudos
Observer gyellen1120
Observer
4,891 Views
Registered: ‎10-28-2013

Re: Ignore combinatorial loop in timing

Jump to solution

I'm sure I want to keep the loop.  It works properly when implemented (in ISE).  These are propagated flags related to a sequentially loaded circular buffer of registers, and the values in the buffer are guaranteed to be sparse (mostly zero), so they won't propagate around in a circle (logic is: 1 if the preceding two flags are zero and the buffer register exceeds threshold, else 0).

 

I'm not quite sure how to use the set_max_delay as you suggest; is this between two specific members of the loop, for example:

 

    set_max_delay -from [[get_nets * -hierarchical -filter {NAME =~ *prevYPeaksIn[0]}] -to [get_nets * -hierarchical -filter {NAME =~ *prevYPeaksIn[1]}]

 

?

 

Thanks - gary

0 Kudos
Historian
Historian
4,865 Views
Registered: ‎01-23-2009

Re: Ignore combinatorial loop in timing

Jump to solution

Generally you would segment the path in one place, which means either you would create a segmented path from the real startpoint to the point you want to break, or from the point you want to break to the real endpoint. This is almost equivalent (from the STA point of view) of converting the broken point into a new static timing startpoint and endpoint (with one of the paths already constrained from the set_max_delay that segmented the path). If you want, you can do both of the above - segment from the startpoint to the pin to be broken and from the pin that is broken to the endpoint (I am pretty sure that the segmented point must be a pin - not a net).

 

Again, it is important to understand, though, that when you do this ALL paths through the segmented point are broken, so you need to manually constrain (via set_max_delay) the paths from all startpoints to the segmented point and from the segmented point to all endpoints.

 

Furthermore, the segemented point is an ideal point - it has no clock, so no clock propagation is done to that point. So, the "path" from the startpoint to the segmented point will do complete analysis of the source clock delay (including any MMCM or PLL that exists on the path, as well as all clock buffers and input buffers), but the segmented point will not have any destination clock delay (since it has no clock). So, for example, if your 10ns clock is driven by a simple BUFG (which can take around 3ns), a normal FF to FF path will have a 10ns requirement (minus some skew and uncertainty), the segmented path will only end up with 7, since the 3ns through the clock network to the startpoint will not be cancelled by a clock to the segmented point...

 

Path segmentation is very messy...

 

Avrum

Tags (1)
0 Kudos