About the "set_false_path" command

[Yamada1]

It would be helpful if you could tell me about the options of the "set_false_path" command.

　1)It is explained that the -setup,-hold option specifies Setup(Recovery) and Hold(Removal) as False paths, but this is the same as clock edge specification, if both Setup and Hold are not specified. Am I correct in understanding that it is considered a false path?

　2) When setting a false path to the first-stage register when synchronizing a signal unrelated to the clock from a DIP SW, etc., is it okay to write -from[input port] -to[register input pin]? Is it necessary to write the CLK input to the first stage register on the -to side?

We apologize for the inconvenience, but it would be helpful if you could enlighten us.

Please note that this may be difficult to understand as it is a machine translation.

[sstrell]

1) It's a "false path" in so far as the indicated analysis is not performed on the path in question.  Normally, set_false_path with no options prevents all analysis on a path (a true cut/false path).  Using -setup with it, for example, means that hold analysis will still be performed but setup analysis will not.

2) Yes, that's exactly how you would do it.  No, you would almost never false path a clock path.  That still has to launch data to the next register.

[Yamada1]

Thank you for answering.

Thank you for your detailed explanation.

In the circuit shown in the figure, if data and reset are asynchronous signals, is the following correct description of the "set_false_path" command?

　Target path1:　set_false_path -from [get_port {data}] -to [get_pins {REG1|datain}]

　Target path2:　set_false_path -from [get_port {reset}] -to [get_pins {REG1|areset}]

Am I correct in my understanding that if you do not want to run only a specific analysis, you should specify options such as -Setup, -Hold, etc. as necessary?

I apologize for asking so many detailed questions, but I would appreciate it if you could explain it to me.

[sstrell]

Asynchronous data input to a register?  Sure you could false path that.  Pretty unusual though.

As for using -setup and -hold with set_false_path, these are rarely used.  The only use I can think of is with DDR interfaces where you need to specify which analyses to not perform between the specific launch and latch edges (rising edge data vs. falling edge data).

[Yamada1]

Thank you for answering.

I'm sorry that I don't have enough words.

I assumed a path from the input port to the first stage register, such as receiving manually operated signals such as toggle switches, and receiving start-stop synchronization signals.

Regarding the description of the "set_false_path" command, am I correct in understanding that there is no problem with the method described in the previous reply?

I apologize for the repeated questions, but I would appreciate it if you could give me some guidance.

[RichardTanSY_Intel]

Should be no problem to use the sdc constraint, if there a problem, you will see the constraint being ignored in the Report Ignored SDC in the Timing Analyzer.

Let me add more info:

The set_false_path command tells the timing analyzer not to analyze a path or group of paths. It can be between keepers (registers, I/Os, etc.) or between clocks.

The -from and -to values are collections of clocks, registers, ports, pins, or cells in the design. If the -from or -to values are not specified, the collection is converted automatically into [get_keepers *]

When the constraint is applied to clocks, then  all paths that are clocked by the respective clock will not be analyzed.

Three examples:

# Cut timing from an input port to all of its destinations:

set_false_path -from [get_ports reset_button]

# Cut timing from a mode_select register, which is static in the design, to all of its destinations:

set_false_path -from [get_keepers *|mode_select]

# Cut timing from clk_a to clk_b:

set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]

The last example cuts timing on all paths where clock clk_a drives the source register and clock clk_b drives the destination register.

Note that transfers in the other direction have not been cut, and another set_false_path assignment would be necessary- set_false_path -from [get_clocks clk_b] -to [get_clocks clk_a]

Cutting timing between clocks is often best accomplished with set_clock_groups.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

I apologize for asking so many questions, but I would appreciate it if you could explain the following points.

1) If a register receives a signal that is completely asynchronous to the FPGA's operating clock, such as a toggle switch, a synchronizer is required. At that time, it is necessary to set a false path between the input port and the first register, but am I correct in assuming that the following description does not cause any problems?

　set_false_path -from [get_ports {DATA}] -to [get_pins {reg|datain}

2) Keepers refers to registers, I/O, etc., so [get_keepers *|mode_select] in Example 2 would probably refer to the mode_select register or mode_select port, but if you use the same register as the port name, Does that mean that if there is a name, both parties will be affected?

Sorry for the basic question, but I would appreciate it if you could explain it to me.

[RichardTanSY_Intel]

1) To set a false path between two clock domains, it is recommended to use:

set_false_path -from [get_clocks clockA] -to [get_clocks clockB]

or

set_clock_group -asynchronous -from [get_clocks A] -to [get_clocks B]

instead of:

set_false_path -from [get_ports {DATA}] -to [get_pins {reg|datain}

You may checkout this youtube video: https://www.youtube.com/watch?v=BNiXxmQlCCs

2. The example 2 that I provided refers to the mode_select register. If you happen to have a mode_select port with the same name as the register, then by using [get_keepers *|mode_select], both may possibly be impacted by the SDC constraints.

While it's technically possible to use the same name for a port and a register, doing so can lead to confusion and make the code harder to understand.

It's generally good practice to use distinct names that clearly convey the purpose of each signal in the design.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

I'm sorry that I don't have enough words.

What we were envisioning was a circuit like the one shown below, and was not the clock switching that you answered.

The intent of question 1) is whether the following description of the falsity path setting for Target path1 is okay if the data in the figure is completely asynchronous with respect to CLK.

　set_false_path -from [get_ports {DATA}] -to [get_pins {reg|datain}

Sorry for the basic question, but I would appreciate it if you could explain it to me.

[RichardTanSY_Intel · Accepted solution]

My apologize for not understand your previous question correctly.

Correct me if I am wrong. This look like asynchronous input to the synchronizer logic.

Setting false path to the [asynchronous input paths to synchronizer logic] (path 1) should be sufficient.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

Thank you for responding to my repeated questions.

I was told that all I had to do was set the phallus path for path 1 in the diagram I presented last time, so I recognized that the following description was OK.

set_false_path -from [get_ports {data}] -to [get_pins {reg1|datain}]

If there is no problem, I would appreciate it if you could let me know.

[RichardTanSY_Intel]

Generally the sdc constraints should not be a problem.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

Thank you for your kind response.

[RichardTanSY_Intel]

No problem. Happy to help. 

Now, I will transition this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out.

Thank you and have a great day!

Best Regards,

Richard Tan