About loading constraints

[Yamada1]

It would be helpful if you could teach me about reading the constraints of the fitter.

There is no particular problem when editing the SDC with Timing Analyzer, but when compiling afterwards, a warning message appears when the fitter reads the SDC.

The steps I followed are as follows.

　1) Compile execution. (Since it is a very small design, it is fully compiled.)

　2) Start the timing analyzer

　3) Execute “Create Timing Netlist”

　4) Execute "Read SDC Flie" to display the SDC File list, then open the SDC File to be edited.

　5) Editing and saving SDC File.

　6) Execute “Read SDC Flie”

　7) Execute “Update Timing Netlist”

　 Run full compilation

The message appears as below after the fitter reads the SDC file.

Info (332104): Reading SDC File: 'TFT_RX.sdc'

Warning (332174): Ignored filter at TFT_RX.sdc(15): s_rlo_clk_det[0]|datad could not be matched with a pin

Warning (332049): Ignored set_false_path at TFT_RX.sdc(15): Argument <to> is an empty collection

Info (332050): set_false_path -from [get_ports {RLO_CLK}] -to [get_pins {s_rlo_clk_det[0]|datad}]

When executing 6), there were no warnings or alarms in the timing analyzer messages.

Also, I edit the SDC file using the GUI (Insert Constraint→Set False Path) instead of manually inputting it, and I also search for pins using Name Finder.

Even if 7) was not executed, the result did not change.

The results did not change even if the first compilation was performed up to logic synthesis instead of full compilation.

In addition, there was no warning or alarm when the timing analyzer read the SDC file during full compilation.

It would be helpful if you could teach me the following points in the above situation.

a) Is it correct to understand that the above message means that the fitter ignores the target set_false_path?

b) Is the reason why the above message appears because the pins have not been determined before fitting?

c) If I change -to [get_pins {s_rlo_clk_det[0]|datad}] to -to [get_registers {s_rlo_clk_det[0]}], the above message no longer occurs, but why?

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

Also, please note that the text may be difficult to understand due to machine translation.

[sstrell]

a) Yes.

b) No.  It means that your target is not valid.  Are you using the Name Finder to search for this pin?  Also, why is a clock input getting connected to a register data input (assuming RLO_CLK is a clock)?

c) datad is probably not the correct name for the data input pin of that register.  Use the Name Finder to find the correct target for a constraint.

[Yamada1]

Thank you for answering.

Sorry for not explaining enough.

The reason why RLO_CLK is connected to the data input is to detect the rise of RLO_CLK, and the result of checking the input part with Technology Map Viewer (Post-Fitting) is shown in the figure below.

Also, I use Name Finder to search for pins. 

"s_rlo_clk_det[0]|datad" can be found in Name Finder as shown below.

In other words, even though you are using the pin name found in Name Finder, the fitter determines that it is not the correct input pin name when reading the SDC file.

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

[RichardTanSY_Intel]

Does the project has multiple sdc file? If so, could you arrange the affected sdc list so that the impacted sdc file will read last. Go to Settings > Timing Analyzer, then select the affected sdc file and click "Down".

My guess is that the tool might potentially read the sdc file first before the pins get to known by the quartus tool. Thus, it could not find the pins.

Just to understand correctly, you saw the warning message appear during compilation. After compilation, you open the Timing Analyzer and run the sdc command in the console, then the sdc constraints work this time.

Do I understand correctly?

If possible, could you share your design (Project > Archive Project) so that I can investigate it further.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

Sorry for the lack of explanation.

This time, the design is small and does not use IP, so there is only one SDC file.

Therefore, the constraints are not overwritten.

It is speculated that the cause of this problem is that the tool reads the SDC file before recognizing the pins, but does this mean that it can be avoided by creating constraints during execution up to logic synthesis?

I checked, and the same phenomenon occurs even when constraints are created after logic synthesis.

In addition, since we search for pins using Name Finder, we do not believe that we are setting a pin that does not exist.

Regarding the phenomenon,

　・A warning message is displayed when the fitter reads an SDC file.

　・If you open the Timing Analyzer and read the SDC file after compilation, no warning message will be displayed.

If you understand that, you are correct.

For additional information:

　・A warning message is not displayed when the timing analyzer reads the SDC file during timing analysis during compilation.

It becomes.

We apologize for not providing the design, but please bear with us as it includes customer information.

[RichardTanSY_Intel]

Hmmm, that will be hard to debug without the design. Could you share a simplified design without customer information? 

To replicate errors by creating a simplified design:

1. Once you have identify the critical functionality that triggers the error in your original design, extract only the essential modules or components from your original design and create a simplified hierarchy.

2. Remove any unnecessary modules or subsystems that are not directly related to the error.

3. Ensure that the design connections and interfaces are properly maintained.

4. Compile the simplified design and ensure that the error reoccurs.

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

As per your suggestion, we will send you a design with only the relevant parts cut out.

We have confirmed that this issue occurs when the design is compiled.

Also, on line 17 of the SDC file, there is a part where a falsity path is set for the output port, and although it seems that the setting itself is set, the number of Unconstrained Output Ports does not decrease and the setting is seems to be ignored.

Although the file is compressed, it is not password protected, so please unzip it and use it.

We apologize for the inconvenience and appreciate your understanding.

[RichardTanSY_Intel]

I may need some additional time to analyze the design thoroughly. I appreciate your patience and understanding in this matter.

Regards,

Richard Tan

[RichardTanSY_Intel]

I try some iterations and the constraints below will works:

set_false_path -from [get_ports {RLO_CLK}] -to [get_pins {s_rlo_clk_det[0]|data*}]

Same with :

set_false_path -from [get_ports {RLO_CLK}] -to [get_pins {s_rlo_clk_det[0]|*}]

My guess is the pin datac might be changeable during compilation/design optimization, causing it not recognizable by the tool. Adding the asterisk (*) wildcard will help to ensure the constraints is applied to objects that match that pattern. In the above sdc example, any path -to the reg or the reg's data pin will be false path.

In future, if you see similar behavior, try to use the asterisk (*) wildcard instead. You can verify whether the false path constraint is applied in the timing analyzer (Report False Path).

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

I understand that this can be avoided by using wildcards.

Also, I just noticed that line 17 of the sdc file doesn't seem to be applied either.

No particular message appears, but when you look at "Unconstrained Paths", RLO_CLK_NODE remains unconstrained.

It would be helpful if you could provide us with information regarding this.

We apologize for the inconvenience and appreciate your understanding.

[RichardTanSY_Intel]

It seems that the path is Invalid in the Report Exception. Invalid means that: No paths are affected by this exception. This occurs when a timing exception has valid -from, -to, or -through collections, but there are no actual paths from the -from nodes to the -to nodes.

You can use the wildcard again to fix that.

set_false_path -from [get_pins {s_rlo_clk_cnt|*}] -to [get_ports {RLO_CLK_NODE}]

You can also use the following false path to removes this port from showing up in the Unconstrained Path:

set_false_path -to [get_ports {RLO_CLK_NODE}]

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

We have confirmed that this can be avoided by using a wildcard for the target as in the case of input ports.

I tried it and realized that I was able to avoid this by changing line 17 of the SDC file as shown below, but is this correct?

　set_false_path -from [get_pins {s_rlo_clk_cnt|clk}] -to [get_ports {RLO_CLK_NODE}]

We apologize for the inconvenience and appreciate your understanding.

[RichardTanSY_Intel]

What is your design requirement and your purpose? Is it to temporary remove the unconstrained path from reporting out? Or exclude the path from analyzed by the timing analyzer?

Regards,

Richard Tam

[RichardTanSY_Intel · Accepted solution]

The constraints you used will remove the Unconstrained path being reported out because the -to node (RLO_CLK_node) that is false path is the same.

At the end, designers need to know their design requirement and know where & when to use set_false_path.  These constraints tell Timing Analyzer not to analyze specific paths or clock transfers. Once a path has been cut by either of these commands, there is no way to un-cut it, i.e. these constraints have the highest priority. 

Regards,

Richard Tan

[Yamada1]

Thank you for answering.

I understand that if the -to nodes are the same, the previous description and when using wildcards will have the same behavior.

In addition, there was a question about the purpose in the comment received at 1:02 AM on 3/18, but the purpose of setting a false path is to "exclude it from being analyzed by the timing analyzer."

Thank you very much for your detailed explanation of the details.

[RichardTanSY_Intel]

Thank for clarify the constraint's intention and also thank you again for acknowledging the solution provided. I'm pleased to know that your question has been addressed. 

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