cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
170 Views
Registered: ‎02-19-2016

Does a set_min_delay of 0 make sense?

Jump to solution

Hey guys,

I'm taking over a design from someone who has left the company and I'm trying to understand his timing constraints.

For several PCI signals, he has something like this:

    set_min_delay 0 - from pci_ad/clk -to PCI_AD

Where pci_ad/clk is the clock of a FF, and the output (Q) of the FF is a net going to PCI_AD, which is an output pad.

Does it make sense to impose a minimum of 0 ns of delay between these signals?  Isn't that redundant?  Of course the tool can't do less than 0ns of delay.

Not sure if these detail matters at all, but additionally, these same paths have a multicycle delay of 2.  Which I guess makes sense.

    set_multicycle_path 2 -from pci_ad/clk -to PCI_AD

Can anyone explain the reasoning for the set_min_delay constraint?

Thanks!

0 Kudos
Reply
1 Solution

Accepted Solutions
Guide
Guide
88 Views
Registered: ‎01-23-2009

Neither of these constraints (alone or together) make sense...

First, these commands are pretty sloppy - you can't tell what type of objects they are referring to. They really should be written as

  set_min_delay 0 -from [get_pins pci_ad/clk] -to [get_ports PCI_AD]

Second, setting a minimum delay on this path doesn't make sense. This is a "normal" path from a flip-flop to an output driven by this flip-flop (either directly or through some logic). This path should be constrained by a set_output_delay with both a -min and a -max. Furthermore, the value 0 is meaningless; the values should be the proper values extracted by the PCI specification (which are very tight).

Third, there is absolutely no reason for this to be a multicycle path. Most likely this command was thrown in because the path was failing and the original designer didn't know why so added this constraint.

How is this PCI interface clocked? Is it a normal "system synchronous" interface; i.e. there is a clock source on the board that clocks both the FPGA and the other side of the PCI link?

In all cases you need to be super careful about the constraints on this interface. As I mentioned, the driver level timings specified by the PCI specification are very tight and will likely be hard to meet in an FPGA. Your clocking structure (almost certainly with the use of an MMCM or PLL to deskew the clock) will need to be precisely tuned to get both the inputs and outputs to meet their timing. In fact, you likely will need two different phases of the clock for inputs and outputs.

If these are the only constraints on these paths (and assuming the interface is working) then this is by pure luck or by trial and error on the board. With these constraints you have no idea how close or far you are to meeting the timing requirements on this PCI bus. 

My suggestion is that you throw away all the constraints for the bus, and write them properly based on the PCI specification.

Avrum

 

View solution in original post

4 Replies
156 Views
Registered: ‎09-17-2018

The tools,

Will try to meet the constraint.  If the tool cannot meet the constraint, it gives up.  So whatever its best effort was before it gave up will be what you are left with.

Absurd constraints may be completely ignored.

The Infos and Warnings will tell you what was done.

It is best practice to constraint with realistic values.  So, to do anything, anywhere, 0 is impossible.  500 ps or 1 ns is more realistic and may still be impossible to achieve.

lowearthorbit

0 Kudos
Reply
Adventurer
Adventurer
144 Views
Registered: ‎02-19-2016

Wouldn't a min delay of 0 be the opposite of impossible?  How could the delay be less than 0?  

0 Kudos
Reply
131 Views
Registered: ‎09-17-2018

Any physical delay is always greater than 0,

Relative delays may easily be positive, negative, or zero.

lowearthorbit

0 Kudos
Reply
Guide
Guide
89 Views
Registered: ‎01-23-2009

Neither of these constraints (alone or together) make sense...

First, these commands are pretty sloppy - you can't tell what type of objects they are referring to. They really should be written as

  set_min_delay 0 -from [get_pins pci_ad/clk] -to [get_ports PCI_AD]

Second, setting a minimum delay on this path doesn't make sense. This is a "normal" path from a flip-flop to an output driven by this flip-flop (either directly or through some logic). This path should be constrained by a set_output_delay with both a -min and a -max. Furthermore, the value 0 is meaningless; the values should be the proper values extracted by the PCI specification (which are very tight).

Third, there is absolutely no reason for this to be a multicycle path. Most likely this command was thrown in because the path was failing and the original designer didn't know why so added this constraint.

How is this PCI interface clocked? Is it a normal "system synchronous" interface; i.e. there is a clock source on the board that clocks both the FPGA and the other side of the PCI link?

In all cases you need to be super careful about the constraints on this interface. As I mentioned, the driver level timings specified by the PCI specification are very tight and will likely be hard to meet in an FPGA. Your clocking structure (almost certainly with the use of an MMCM or PLL to deskew the clock) will need to be precisely tuned to get both the inputs and outputs to meet their timing. In fact, you likely will need two different phases of the clock for inputs and outputs.

If these are the only constraints on these paths (and assuming the interface is working) then this is by pure luck or by trial and error on the board. With these constraints you have no idea how close or far you are to meeting the timing requirements on this PCI bus. 

My suggestion is that you throw away all the constraints for the bus, and write them properly based on the PCI specification.

Avrum

 

View solution in original post