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!

Reply

What does "set_false_path -through..." do?

Accepted Solution Solved
Adventurer
Adventurer
Posts: 77
Registered: ‎05-18-2011
Accepted Solution

What does "set_false_path -through..." do?

Background:

I have a Zynq based design to which I have added my own IP.  In the process of adding my IP and running the various block automation scripts, a "Processor System Reset" module was added to my design.  I use the peripheral_aresetn output of that module to reset my custom IP.  I added a clocking wizard to generate a 320 MHz clock (from the 100 MHz FCLK[0] output of the PL) to clock my IP.

 

When I implement my design, I get a timing violation from the output of the reset module (clocked at 100 MHz) to one of the flops in my design (clocked at 320 MHz).  But when I look at the timing constraints for the implemented design, I see that there is a:

 

set_false_path -through [get_pins design_1_i/rst_processing_system7_0_100M/U0/ext_reset_in]

 

constraint that was added by the reset module's .xdc file.

 

When I look at the Vivado TCL command reference (UG835), I see the set_false_path command described as:

 

Sets false timing paths in the design that are ignored during timing analysis.

 

with the -through option described as:

 

(Optional) List of through pins, cells or nets

 

There are also options listed for -setup, -hold, -rise, -fall, etc...  I note that none of these are listed on the set_false_path command provided by the reset module .xdc file.  I wonder if one or more of those should be added to the command.

 

From the context, (in the .xdc file) I would have expected the set_false_path command to indicate to Vivado that it should ignore paths that pass through the ext_reset_in pin for the reset module, and thus I should not be getting a timing constraint violation originating from a flop inside that module.

 

So now I am wondering, what does "set_false_path -through..." do?  The description in UG835 is not enough for me to understand.  Is there another/better description of this command and its arguments that I can read someplace?

 

On a related note, I started off wanting to specify my own false path constraint when I discovered this one, which looked like it should already cover this.  I wanted to name my 320 MHz block design clock net clk320 so I could specify it more descriptively than the clk_out1_design_1_clk_wiz_0_0 name that was automatically generated by Vivado.  So I named the net clk320 in the block diagram.  But it is still named clk_out1_design_1_clk_wiz_0_0.  Is there some way I can change the name of that clock?

 

 

Thank you for your help.

 

--wpd

 


Accepted Solutions
Highlighted
Historian
Posts: 4,540
Registered: ‎01-23-2009

Re: What does "set_false_path -through..." do?

A static timing path is defined as a path that starts at a clocked element (technically at the clock pin of that clocked element), propagates through any number of combinatorial elements and the nets that interconnect them, and ends at a clocked element (technically the data input pin of the clocked element).

 

The set_false_path command (as its name implies) declares one or more static timing paths as false. That means that the normal timing checks (setup and hold) that are usually performed on the path are not done.

 

The "tricky" thing about the set_false_path command is identifying the path or paths that should be declared false. This is done by "path enumeration" - describing the path or set of paths to the tool so it knows which ones to set false. Within Vivado (and SDC/XDC) path enumeration is done the same way for all commands that need to select paths (these being the timing exception commands, set_false_path, set_multicycle_path, set_min_delay, set_max_delay and the path reporting commands, like report_timing, get_timing_paths).

 

The mechanism for doing path enumeration is done using the -from, -to -through (and corresponding -rise_from, -rise_through, -fall_from, -fall_through -fall_to) options. The -from option gives the tool a list of clocked elements which are the start points of paths to be enumerated. The -to gives a list of clocked elements which are the end points of paths to be enumerated. The -through option gives a list of pins or nets which the path must pass through to be enumerated. These three options (and their variants) can be used together or separately; specifying a -from, a -through, and a -to will enumerate only paths that start at one of the listed startpoints, pass through at least one of the specified through points, and end at one of the specified end points.

 

If you specify only a -through, then it means "starts at any clocked element, passes through the specified through point, and ends at any clocked element". Thus the command you are seeing sets as false all paths that pass through the pin design_1_i/rst_processing_system7_0_100M/U0/ext_reset_in

 

Now, lets examine reset.

 

The tool is 100% correct in identifying a timing failure between a path that starts at a clocked element on the 100MHz domain and ends at a clocked element on the 320MHz domain. This is a timing failure. It doesn't matter that this is a "reset" signal - even a reset that is connected to the "asynchronous preset/clear" pin of a flip flop must be synchronous. It is not correct to simply declare this path as being false.

 

In order to generate a proper reset for the 320MHz domain, you need to synchronize your reset to the 320MHz domain before using it to reset flip-flops in this domain. This is done with a "reset bridge" (see attachment). This circuit takes a "reset" signal (rst_in) that is asynchronous to the destination clock domain (dst_clk) and synchronizes the deasserting edge (rst_out). This is required to ensure that the design comes out of reset properly.

 

With this reset bridge, the input to the reset bridge can now be declared a false path. This can be done by (for example)

 

set_false_path -through [get_pins reset_bridge_i0/rst_in]

 

It is my suspicion that the Processor System Reset block is doing exactly this - it is taking in an asynchronous input reset (named ext_reset_in) and synchronizing it to the 100MHz domain using a reset bridge. So this constraint is disabling the path on the reset_bridge's input - not its output.

 

So, what you need to do is create your own reset bridge for the 320MHz domain, and then use the synchronized reset in your 320MHz domain. The input to the 320MHz domain reset bridge is a reset that is asynchronous to the 320MHz domain (though probably synchronous to the 100MHz domain). With the reset bridge in place, you could now add a set_false_path through the input of the 320MHz domain reset bridge.

 

As for renaming the clock, you need to realize that the name of the net that carries the clock and the name of the clock are not the same thing. A clock is an XDC object. You can see all the clock objects by using the report_clocks command. The clock is attached to a net in the design, and propagates forward. The name of the net doesn't (necessarily) have anything to do with the name of the clock. In this case, the clock is generated automatically by the tools when a primary input clock (in this case a clock from the PS) reaches an MMCM - the tool automatically generates new generated clocks for the outputs of the MMCM. The names it uses for the generated clocks are relatively arbitrary. You can "rename" the clock through the clock wizard (at least in the latest versions of the tool), but I maintain that you don't really care what the clock is named... If you want to use the clock for the purposes of the constraints, then just "get" it using the formats provied by XDC. If you know the clock is on the net "clk320", then just get it using

 

get_clocks -of_objects [get_nets clk320]

 

This will return the clock. You can use this directly in a command that needs the clock like

 

set_input_delay -clock [get_clocks -of_objects [get_nets clk320]] 3 [all_inputs]

 

If you want, you can use a Tcl variable

 

set clk_320 [get_clocks -of_objects [get_nets clk320]]

set_input_delay -clock $clk_320 3 [all_inputs]

 

Avrum

 

 

View solution in original post


All Replies
Highlighted
Historian
Posts: 4,540
Registered: ‎01-23-2009

Re: What does "set_false_path -through..." do?

A static timing path is defined as a path that starts at a clocked element (technically at the clock pin of that clocked element), propagates through any number of combinatorial elements and the nets that interconnect them, and ends at a clocked element (technically the data input pin of the clocked element).

 

The set_false_path command (as its name implies) declares one or more static timing paths as false. That means that the normal timing checks (setup and hold) that are usually performed on the path are not done.

 

The "tricky" thing about the set_false_path command is identifying the path or paths that should be declared false. This is done by "path enumeration" - describing the path or set of paths to the tool so it knows which ones to set false. Within Vivado (and SDC/XDC) path enumeration is done the same way for all commands that need to select paths (these being the timing exception commands, set_false_path, set_multicycle_path, set_min_delay, set_max_delay and the path reporting commands, like report_timing, get_timing_paths).

 

The mechanism for doing path enumeration is done using the -from, -to -through (and corresponding -rise_from, -rise_through, -fall_from, -fall_through -fall_to) options. The -from option gives the tool a list of clocked elements which are the start points of paths to be enumerated. The -to gives a list of clocked elements which are the end points of paths to be enumerated. The -through option gives a list of pins or nets which the path must pass through to be enumerated. These three options (and their variants) can be used together or separately; specifying a -from, a -through, and a -to will enumerate only paths that start at one of the listed startpoints, pass through at least one of the specified through points, and end at one of the specified end points.

 

If you specify only a -through, then it means "starts at any clocked element, passes through the specified through point, and ends at any clocked element". Thus the command you are seeing sets as false all paths that pass through the pin design_1_i/rst_processing_system7_0_100M/U0/ext_reset_in

 

Now, lets examine reset.

 

The tool is 100% correct in identifying a timing failure between a path that starts at a clocked element on the 100MHz domain and ends at a clocked element on the 320MHz domain. This is a timing failure. It doesn't matter that this is a "reset" signal - even a reset that is connected to the "asynchronous preset/clear" pin of a flip flop must be synchronous. It is not correct to simply declare this path as being false.

 

In order to generate a proper reset for the 320MHz domain, you need to synchronize your reset to the 320MHz domain before using it to reset flip-flops in this domain. This is done with a "reset bridge" (see attachment). This circuit takes a "reset" signal (rst_in) that is asynchronous to the destination clock domain (dst_clk) and synchronizes the deasserting edge (rst_out). This is required to ensure that the design comes out of reset properly.

 

With this reset bridge, the input to the reset bridge can now be declared a false path. This can be done by (for example)

 

set_false_path -through [get_pins reset_bridge_i0/rst_in]

 

It is my suspicion that the Processor System Reset block is doing exactly this - it is taking in an asynchronous input reset (named ext_reset_in) and synchronizing it to the 100MHz domain using a reset bridge. So this constraint is disabling the path on the reset_bridge's input - not its output.

 

So, what you need to do is create your own reset bridge for the 320MHz domain, and then use the synchronized reset in your 320MHz domain. The input to the 320MHz domain reset bridge is a reset that is asynchronous to the 320MHz domain (though probably synchronous to the 100MHz domain). With the reset bridge in place, you could now add a set_false_path through the input of the 320MHz domain reset bridge.

 

As for renaming the clock, you need to realize that the name of the net that carries the clock and the name of the clock are not the same thing. A clock is an XDC object. You can see all the clock objects by using the report_clocks command. The clock is attached to a net in the design, and propagates forward. The name of the net doesn't (necessarily) have anything to do with the name of the clock. In this case, the clock is generated automatically by the tools when a primary input clock (in this case a clock from the PS) reaches an MMCM - the tool automatically generates new generated clocks for the outputs of the MMCM. The names it uses for the generated clocks are relatively arbitrary. You can "rename" the clock through the clock wizard (at least in the latest versions of the tool), but I maintain that you don't really care what the clock is named... If you want to use the clock for the purposes of the constraints, then just "get" it using the formats provied by XDC. If you know the clock is on the net "clk320", then just get it using

 

get_clocks -of_objects [get_nets clk320]

 

This will return the clock. You can use this directly in a command that needs the clock like

 

set_input_delay -clock [get_clocks -of_objects [get_nets clk320]] 3 [all_inputs]

 

If you want, you can use a Tcl variable

 

set clk_320 [get_clocks -of_objects [get_nets clk320]]

set_input_delay -clock $clk_320 3 [all_inputs]

 

Avrum

 

 

Adventurer
Adventurer
Posts: 77
Registered: ‎05-18-2011

Re: What does "set_false_path -through..." do?

Hello Avrum,

Thank you for your fabulously clear explanation.  I am surprised not to be able to find a reset bridge module in Xilinx's packaged IP, but it was trivial to implement my self (plus good practice at creating my own IP.)

 

For my own benefit (when I come back to read this thread 3 weeks from now), the get_nets clk320 command you mentioned didn't "just work" (when I tried it at the Tcl command prompt).  I had to add the -hierarchical option in order to find it, since it was buried inside a block diagram.  But this was documented quite clearly in UG835, so that was easy.

 

Now all I need to do is to figure out why the inter-clock timing is failing. :-)

 

Thank you again for your quick, and incredibly clear, response to my question.

--wpd

 

Adventurer
Adventurer
Posts: 77
Registered: ‎05-18-2011

Re: What does "set_false_path -through..." do?

Continuing on...

 

As I have been experimenting with different incarnations of my design, I managed to connect my reset input to the FCLK_RESET0_N output from the Zynq PS.  When I did that, my timing violation disappeared.  Now I'm curious, why did that happen?

Is there something magic inside the Zynq PS that makes the FCLK_RESET0_N output synchronous to everything it touches?  (I knda doubt that).

 

Is there a magic false path constraint that is implicitly defined by the procssing system?  I don't see it in the "Edit Timing Constraints" window in the Vivado GUI.

 

--wpd