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: 
Adventurer
Adventurer
739 Views
Registered: ‎06-30-2013

Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

I am working on a Zynq XC7Z030 design that has some control and low frequency signals that leave the FPGA and do not require tight timing.

Originally I used  set_output_delay constraints with zero for trace delay and setup/hold

Tool uses 10ns virtual clock to match period of internal 100MHz clock.  Here is an example

set_output_delay -clock [get_clocks VIRTUAL_pl_clk100M_out_pl_clock_manager] -min -add_delay 0.000 [get_ports FPGA_I2C_SCL]

set_output_delay -clock [get_clocks VIRTUAL_pl_clk100M_out_pl_clock_manager] -max -add_delay 0.000 [get_ports FPGA_I2C_SCL]

 

Even with zero external delays and 10ns virtual clock I fail timing as shown below:

 

constraint2.PNG

 constraint1.PNG

Since I do not really care about the timing for 100kHz I2C ports and the other control signals,  I used a false path constraint as shown below:

 

Add false path constraints:

set_false_path -from [get_pins -hier -filter {NAME =~ *base_zynq_i/vfarcvr_0/U0/vfa_top_0/front_panel_0/i2c_master_block_0/scl_i_reg*/C}] -to [get_ports FPGA_I2C_SCL]

 

This seems to fix the problem but is this the correct way to address such an issue?  Also, I am concerned that I only want to leave the path from the output of any clocked element out through the IO buffers as unconstrained.  I do not want to make other paths that should be timed unconstrained.  I think I found the actual register that drove the signal but I am not sure how to verify that I have the correct unconstrained path.  Can I do this with a timing summary report option?

 

Thank you!

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
670 Views
Registered: ‎01-23-2009

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

when is a set_false_path really the best option?

In my opinion, pretty rarely - generally speaking far more rarely than it is actually used.

A false path should really be used only if:

  • The source never (and I mean never) changes state (i.e. the signal is static)
    • This happens sometimes in ASICs that have multiple modes, where a config pin tied to a VCC or GND on a board to configure it's behavior
    • FPGAs rarely do this (since it is easy to have multiple bitstreams for different boards)
  • The source only changes states when some other condition makes the value irrelevant until long after the change (i.e. the signal is pseudo-static)
    • For example CPU accessible control registers that can only be changed while the datapath they control are held in reset or a similar inactive state
    • Even here, the path isn't truly "false" it is simply a multicycle path with a large number of cycles (determined by the minimum separation between the changing of the "reset/enable" signal and the changing of the pseudo-static registers)
  • The path is truly asynchronous - in the meaning that it "has no timing" - i.e. a signal going to an LED output, or an input coming from an asynchronous source
    • An asynchronous input must be properly synchronized before being used
    • An asynchronous reset input pin falls in this category - the input itself can be a false path, but it must pass through a synchronizer (a reset bridge) before it is used to reset flip-flops (and this is true regardless of whether the flip-flops have synchronous set/reset or asynchronous preset/clear)
      • And it is DEFINITELY not false between the synchronizer and the flip-flops - even if the flip-flops use "asynchronous preset/clear" inputs
        • It is these paths that are allowed to have asynchronous assertion with synchronous deassertion - that's what the reset bridge does
  • Where the path is structurally impossible
    • For example a path that goes through two different MUXes where it is structurally guaranteed that at any one time one of the two MUXes will always select the other input of the MUX

Off the top of my head, that's it. 

Many of the other reasons that people use false_paths are not sufficient in my mind.

Simply because two clocks are asynchronous doesn't mean you can declare paths between them as false - in fact, this is almost always incorrect. But people do it all the time (using the horribly dangerous set_clock_groups command) - this leads to designs that can fail.

Similarly just because the timing on a signal or interface is "loose" (like what you are describing above) is also not sufficient - even if it is loose and one thinks "it can't possible be so slow that it will fail", without a constraint you can never know. If it is loose then put a bounding constraint on it just to be sure it is never slower than your bounding constraint - since you think the constraint isn't necessary, then the constraint will not place much (or any) stress on the placer/router, so it has no cost (unless you are wrong, in which case it saves your behind!).

So that's my two cents...

Avrum

Tags (1)
0 Kudos
5 Replies
Explorer
Explorer
725 Views
Registered: ‎07-18-2018

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

Why did you decide on a Virtual Clock?

How is this path running at 100Khz?

A false path if you are correct is unlikely to hurt you. But it's hard to know if that's the best solution with the information provided. It looks like you are forwarding the signal against a very fast Virtual Clock.

0 Kudos
Historian
Historian
696 Views
Registered: ‎01-23-2009

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

For very slow interfaces (like I2C and SPI) the outputs of the FPGA are almost always generated by faster clocks (in this case 100MHz), and the inputs are often oversampled by a similar (or the same) fast clock. In these cases, the setup and hold requirements (on both ends) are usually significantly longer than one period of the faster clock - as a result, these timings are often met not by conventional static timing, but by counting the appropriate number of fast clocks between events on the interface.

For these kinds of interfaces, conventional constraints are somewhat meaningless...

But, to ensure their proper operation we generally do want some kind of control over the signals. For example, we don't want (say) the SCL output to have a very small delay from the driving flip-flop to the pad, but the SDA data to have a huge routing delay inside the FPGA that the SCL does not have. Without constraints and without some "other" way of controlling this path, the tools are free to do literally anything they want - they can route a signal all the way around the edge of the FPGA, incurring an essentially unlimited routing delay.

The best way to control (or really prevent) this is to use the IOB flip-flops - and this is highly recommended for all interfaces (fast and slow). If you ensure that all your outputs are driven directly from flip-flops (the one you show is not - it has a LUT between the flip-flop and the OBUF) then you can set the IOB property to true on the port

set_property IOB TRUE [get_ports {FPGA_I2C_SCL FPGA_I2C_SDA}]

If the ports are driven from the IOB flops, there is almost no variation in the delay between the final (IOB) flip-flop and the IOB pad (the pin of the FPGA). (It is a little complicated to do this with I2C since the outputs are open-drain, but there are IOB flip-flops on the "enable" control of the pad as well as the data, so it can be done).

The same is true for inputs - these too should be captured in the IOB flip-flop.

Once you do this, constraints become irrelevant. However, if you do not constrain them (i.e. you have no set_output_delay), then you will get a warning from the "check_timing" which is run by default. So to fix that, you give it a constraint and then you declare the path false. To declare the path false, it is usually sufficient just to specify the -to [get_ports...] - you don't need the -from. So simply

set_output_delay -clock <any_clock> <any_value> [get_ports {FPGA_I2C_SCL FPGA_I2C_SDA}]
set_ false_path -to                                                        [get_ports {FPGA_I2C_SCL FPGA_I2C_SDA}]

The <any_clock> can be your virtual clock (or pretty much any other clock) and the <any_value> can be 0.

While we are looking at the commands, do NOT put the -add_delay in the set_output_delay/set_input_delay commands. I know the constraint wizard puts them in, but the are wrong. At best they are not needed and harmless, at worst they can lead to some really odd behavior - don't use them unless you need them (and the most common place they are needed are for the falling edge constraints for DDR interfaces). And you also don't need a separate -min and -max - without the -min/-max option, the set_output_delay constrains both to the same value (which is generally wrong, but fine in this case since the value is irrelevant).

Avrum

Highlighted
Adventurer
Adventurer
682 Views
Registered: ‎06-30-2013

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

Thanks Avrum.  That was just the kind of insight I was asking for.  I will try using the IOB TRUE constraint and see how that goes.  While I could easily tolerate 30 or 40 ns of skew between the signals, I like the idea that you suggest.

I guess my follow-up question because I have been so confused over the years as to when is a set_false_path really the best option?  Some have said for reset paths but from all I have read it is best to treat reset control synchronous for de-assertion so I am not even sure making an async reset a false path is a good idea.

 

Craig

0 Kudos
Historian
Historian
671 Views
Registered: ‎01-23-2009

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

when is a set_false_path really the best option?

In my opinion, pretty rarely - generally speaking far more rarely than it is actually used.

A false path should really be used only if:

  • The source never (and I mean never) changes state (i.e. the signal is static)
    • This happens sometimes in ASICs that have multiple modes, where a config pin tied to a VCC or GND on a board to configure it's behavior
    • FPGAs rarely do this (since it is easy to have multiple bitstreams for different boards)
  • The source only changes states when some other condition makes the value irrelevant until long after the change (i.e. the signal is pseudo-static)
    • For example CPU accessible control registers that can only be changed while the datapath they control are held in reset or a similar inactive state
    • Even here, the path isn't truly "false" it is simply a multicycle path with a large number of cycles (determined by the minimum separation between the changing of the "reset/enable" signal and the changing of the pseudo-static registers)
  • The path is truly asynchronous - in the meaning that it "has no timing" - i.e. a signal going to an LED output, or an input coming from an asynchronous source
    • An asynchronous input must be properly synchronized before being used
    • An asynchronous reset input pin falls in this category - the input itself can be a false path, but it must pass through a synchronizer (a reset bridge) before it is used to reset flip-flops (and this is true regardless of whether the flip-flops have synchronous set/reset or asynchronous preset/clear)
      • And it is DEFINITELY not false between the synchronizer and the flip-flops - even if the flip-flops use "asynchronous preset/clear" inputs
        • It is these paths that are allowed to have asynchronous assertion with synchronous deassertion - that's what the reset bridge does
  • Where the path is structurally impossible
    • For example a path that goes through two different MUXes where it is structurally guaranteed that at any one time one of the two MUXes will always select the other input of the MUX

Off the top of my head, that's it. 

Many of the other reasons that people use false_paths are not sufficient in my mind.

Simply because two clocks are asynchronous doesn't mean you can declare paths between them as false - in fact, this is almost always incorrect. But people do it all the time (using the horribly dangerous set_clock_groups command) - this leads to designs that can fail.

Similarly just because the timing on a signal or interface is "loose" (like what you are describing above) is also not sufficient - even if it is loose and one thinks "it can't possible be so slow that it will fail", without a constraint you can never know. If it is loose then put a bounding constraint on it just to be sure it is never slower than your bounding constraint - since you think the constraint isn't necessary, then the constraint will not place much (or any) stress on the placer/router, so it has no cost (unless you are wrong, in which case it saves your behind!).

So that's my two cents...

Avrum

Tags (1)
0 Kudos
Adventurer
Adventurer
640 Views
Registered: ‎06-30-2013

Re: Is a false_path constriaint the best option for control signals leaving the FPGA

Jump to solution

Thanks Avrumw - that was very useful info. 

0 Kudos