cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Explorer
Explorer
549 Views
Registered: ‎03-26-2010

Vivado tight setup and hold pins report on related clocks

Jump to solution

Hi all,

 

I've got a Virtex-7 design implementing in 2019.2 that's reporting some issues with hold time. In the beginning of route I get the tight_setup_hold_pins.txt file generated, and runme.txt reports 6057 pins with tight setup and hold constraints.

Absolutely all of the pins in tight_setup_hold_pins.txt are for related clocks. For example:

+--------------------------+--------------------------+----------------------------------------------------------------------------------------------------------+
| Launch Clock | Capture Clock | Pin |
+--------------------------+--------------------------+----------------------------------------------------------------------------------------------------------+
| fe80_clk | fe40_clk |u_rw_nx_top_v7_wrapper_u0/u_rw_nx_top/u_RIUKarstTop/U_RIUCORE/u_frontend0/u_hbf20_lpf4040/s0_swp_q_reg[0]/D|

Where fe_clk is 160MHz, fe80_clk is 80MHz, fe40_clk is 40MHz, and they are all coming out of the same MMCM.

 

The only constraint on the paths is marked those paths as multicycle in the following way:

 

set_multicycle_path -from [get_clocks fe_clk] -to [get_clocks fe40_clk] 4
set_multicycle_path -from [get_clocks fe_clk] -to [get_clocks fe40_clk] 3 -hold
set_multicycle_path -from [get_clocks fe_clk] -to [get_clocks fe80_clk] 2
set_multicycle_path -from [get_clocks fe_clk] -to [get_clocks fe80_clk] 1 -hold
set_multicycle_path -from [get_clocks phy_clk] -to [get_clocks svd_clk] 2
set_multicycle_path -from [get_clocks phy_clk] -to [get_clocks svd_clk] 1 -hold

 

Is there something wrong I'm doing to this design that's making it harder to meet timing? I would have thought that going from a 40MHz FF into the 80MHz FF there's no point in constraining the whole path to the 80MHz period, cause it will be getting signals at the 40MHz period the entire time.

 

Thanks for any assistance!

0 Kudos
Reply
1 Solution

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

I don't know about the "tight_setup_hold_pins.txt", but you shouldn't be constraining your MMCM this way.

The tools fully understand the MMCM and will automatically generate the output clocks of the MMCM - all you need to do is do a "create_clock" on the port of the FPGA that brings the clock in (and presumably feeds the CLKIN of the MMCM) - the tools will automatically generate all the output clocks, including fully understanding the timing relationships between them (allowing synchronous clock crossings between them). IF... (I will get back to this).

To see this, remove all your set_multicyle_path commands, and do a "report_clocks" to see the derived clocks - it will show you not only the clocks, but the relationships between them (as if they were created by create_generated_clock commands).

In fact, I suspect that your set_multicycle_path commands are incorrect - the tools already understand that (say) fe80_clk is double the period of fe_clk, so your multicycle_path is telling it that it can take 2 periods for propagation. There are two potential problems with this

  • 2 cycles of which clock? It matters, since they are not the same. By default, the tools use the start clock as the period (which is correct in this case), but can be overridden with the -end option of the set_multicycle_path command
  • Your assumption (stated below) isn't correct
    • I would have thought that going from a 40MHz FF into the 80MHz FF there's no point in constraining the whole path to the 80MHz period, cause it will be getting signals at the 40MHz period the entire time.

Lets look at this assumption. You are saying that a signal that changes on the rising edge of clk40 can take one complete clk40 period to get to the destination flip-flop. Normally, this is not true. Lets say that this signal does indeed take more than one clk80 period; during the rising edge of clk80 between two clk40 rising edges, the signal at the input of the flip-flop could be in transition; by your constraint it isn't guaranteed to be stable until after the 2nd clk80 rising edge. Since the signal isn't stable, the clk80 flip-flop may sample it at the old value, the new value or go metastable. This is bad - unless you have specifically designed for this, this will crash your system. So the "normal" constraint for this path (which is what the tool assumes) is one 80MHz clock period.

If, and only if, you have designed a special circuit whereby the flops on the 80MHz domain that capture signals coming from the 40MHz domain only update on the rising edges of clk80 that correspond to rising edges of clk40 (which can be done), then you can declare this path multicycle.

Now back to my "IF..." You can only synchronously cross between clock domains if they are "well balanced". In the FPGA, this means

  • They come from the same MMCM (at least this is sufficient, there are other things that are also legal)
    • You state that this is the case in your system
  • They use the same clocking structure; i.e. they use the same kind of clock network, which means the same (or similar) clock buffer
    • They either all use BUFGs (or one of the derivatives of the BUFG) or BUFHs, but not a mix of the two (at least for the 7 series)
  • If this is an UltraScale or UltraScale+ (or presumably Versal) device, the nets which are the outputs of the BUFGs are in the same CLOCK_DELAY_GROUP

Avrum

View solution in original post

0 Kudos
Reply
2 Replies
Guide
Guide
505 Views
Registered: ‎01-23-2009

I don't know about the "tight_setup_hold_pins.txt", but you shouldn't be constraining your MMCM this way.

The tools fully understand the MMCM and will automatically generate the output clocks of the MMCM - all you need to do is do a "create_clock" on the port of the FPGA that brings the clock in (and presumably feeds the CLKIN of the MMCM) - the tools will automatically generate all the output clocks, including fully understanding the timing relationships between them (allowing synchronous clock crossings between them). IF... (I will get back to this).

To see this, remove all your set_multicyle_path commands, and do a "report_clocks" to see the derived clocks - it will show you not only the clocks, but the relationships between them (as if they were created by create_generated_clock commands).

In fact, I suspect that your set_multicycle_path commands are incorrect - the tools already understand that (say) fe80_clk is double the period of fe_clk, so your multicycle_path is telling it that it can take 2 periods for propagation. There are two potential problems with this

  • 2 cycles of which clock? It matters, since they are not the same. By default, the tools use the start clock as the period (which is correct in this case), but can be overridden with the -end option of the set_multicycle_path command
  • Your assumption (stated below) isn't correct
    • I would have thought that going from a 40MHz FF into the 80MHz FF there's no point in constraining the whole path to the 80MHz period, cause it will be getting signals at the 40MHz period the entire time.

Lets look at this assumption. You are saying that a signal that changes on the rising edge of clk40 can take one complete clk40 period to get to the destination flip-flop. Normally, this is not true. Lets say that this signal does indeed take more than one clk80 period; during the rising edge of clk80 between two clk40 rising edges, the signal at the input of the flip-flop could be in transition; by your constraint it isn't guaranteed to be stable until after the 2nd clk80 rising edge. Since the signal isn't stable, the clk80 flip-flop may sample it at the old value, the new value or go metastable. This is bad - unless you have specifically designed for this, this will crash your system. So the "normal" constraint for this path (which is what the tool assumes) is one 80MHz clock period.

If, and only if, you have designed a special circuit whereby the flops on the 80MHz domain that capture signals coming from the 40MHz domain only update on the rising edges of clk80 that correspond to rising edges of clk40 (which can be done), then you can declare this path multicycle.

Now back to my "IF..." You can only synchronously cross between clock domains if they are "well balanced". In the FPGA, this means

  • They come from the same MMCM (at least this is sufficient, there are other things that are also legal)
    • You state that this is the case in your system
  • They use the same clocking structure; i.e. they use the same kind of clock network, which means the same (or similar) clock buffer
    • They either all use BUFGs (or one of the derivatives of the BUFG) or BUFHs, but not a mix of the two (at least for the 7 series)
  • If this is an UltraScale or UltraScale+ (or presumably Versal) device, the nets which are the outputs of the BUFGs are in the same CLOCK_DELAY_GROUP

Avrum

View solution in original post

0 Kudos
Reply
Explorer
Explorer
497 Views
Registered: ‎03-26-2010

Hi Avrum,

 

Thank you for helping me with this! Your posts are excellent, this is great to see.

 

Basically, from what I'm seeing here is that the multicycle paths are making an assumption that may not be safe. Hence it's best to remove them and run at the higher clock rate.

 

The "tight_setup_hold_pins.txt" file comes out the placer, that's where the tight placement and hold paths are all listed.

0 Kudos
Reply