Routing constraints in QPP

[Pack_of_lone_wolves]

I'm aware of Logic Lock feature in QPP, through which I can restrict the placement of a design node on the FPGA chip. How do I restrict the routing of a data path as well as a clock path in QPP? like placing two earlier distant modules near using logic lock may reduce the data path delay but may increase the clock path delay at either the source or destination node.

I'd like to restrict the such path length or at least direct the tool to go for best minimum possible.

[sstrell]

In the Pro edition, a routing region is associated with an LL region to contain routing.  This is used for certain design flows like partial reconfiguration.

But it's usually better to focus on your timing constraints in your .sdc to guide routing in order to meet timing requirements.

[Pack_of_lone_wolves]

The problem is that I don't know what goes into developing constraints. And based on the awareness that I have about the timing issues that I face these days, I don't think changing timing constraints would solve them. In these issues, clock skew and data path length are the main reason for negative slack.

[Kenny_Tan]

I would suggest to let Quartus route by itself, controlling the routing might cause other path failed in the timing. Quartus prime usually will try his best to route to meet the timing closure, if it does not happened, you can run multiple seeds in the DSE to see if the design able to close the timing.

Any reason that you want to control the routing?

[Pack_of_lone_wolves]

Timing closure is the primary reason. Another reason is to explore more PnR space. I agree that other failures might occur, but I still want to know how to tightly control routing? Solving timing issues because of combinational delays seems more easy to me rather than those due to routing congestion and interconnect delays.

I don't like clock arrival delays getting in the range of several nanoseconds. I want to get the shortest path possible for that. 

[sstrell · Accepted solution]

This is all handled by clock and other timing constraints.  I'd suggest getting familiar with your .sdc file.

User guide: https://www.intel.com/content/www/us/en/docs/programmable/683243.html

Training: https://learning.intel.com/developer/learn/courses/201/understanding-timing-analysis-in-fpgas, https://learning.intel.com/developer/learn/learning-plans/244/timing-analysis-with-the-intelr-quartusr-prime-pro-software

[Pack_of_lone_wolves]

If I have doubts after going through these courses, I'll come back. Thank You for sharing these resources.

[Kenny_Tan]

If you have high congestion within an area, my suggestion is to split out your logic into different area to reduce the congestion. May I know what device and Quartus version that you are using? As we have different method for different version and device.

[Pack_of_lone_wolves]

Using Arria 10 device and QPP v 20.1. 

I'd like to experiment with what you just said, however, I feel that if I try splitting the logic into different areas using logic lock, I might end up worsening the existing delays.

[Pack_of_lone_wolves]

What I also suspect and have a question is that what role can pin planning in assignment editor can play in making timing closure more difficult? The project has multiple clocks and I feel that position of the clock pins is responsible for introducing large clock skews.

[Kenny_Tan]

Not sure if you heard of the "black hole effect" Usually, the reason that the logic pull together is because there are single register pulling all the logic together. Those register are usually reset logic.

What you can do is look into the high fan out register, understand the span of those register, and start duplicating those register to release the high congestion. I will see if I can find some good documentation for you to refer.

[Pack_of_lone_wolves]

I'll check and update on this. I think Design Assistant (DRC) under Timing Analyzer can check for failure of what you have described. Are you suggesting the need to synchronize asynchronous reset? 

[Kenny_Tan]

That is correct, synchronization of the reset is usually a common practice that we do in FPGA. Especially we want to check the recovery and removal time.

Unless you send us your design, it will be hard for me to analyze on this., For your situation, leverate the DRC to look for high tension register, and start duplicating it. I will send you more steps that can be automate after you pipeline the register.

[Kenny_Tan]

Here are the steps:

1) If you identify reset is your high tension / high span of register:

a) turn off the global signal the the reset register to use local routing.

b) Pipeline to increase the syhronizer chain.

c) set_instance_assignment -name DUPLICATE_HIERARCHY_DEPTH 5 -to rstPipeline_i1|pipe5

Try the value from range 3 to 6 to push the register inside to reduce the span and tension of the register.

2) If you identify dflop is your high tension/high span of the register:

a) Pipeline the register

b) set assignment Synchronizer Identification “Off” to all the pipeline registers added. Otherwise, those pipeline registers added can’t be retimed if being identified as synchronizer.

C) set_instance_assignment -name DUPLICATE_HIERARCHY_DEPTH 5 -to rstPipeline_i1|pipe5

Try the value from range 3 to 6 to push the register inside to reduce the span and tension of the register.

Let me know if the above steps helps, what you need to monitor is that after you do the above, you will notice that the congestion start to split over your design instead of concentrating to one particular region.

[Kenny_Tan]

Forget to add on:

DUPLICATE_HIERARCHY_DEPTH information can be find in below:

 https://www.intel.com/content/www/us/en/docs/programmable/683641/21-3/automatic-register-duplication-hierarchical.html

While Synchronizer Identification “Off” is only needed only when you spot the targeted register is in CDC mode.