- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I have doubts after going through these courses, I'll come back. Thank You for sharing these resources.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Forget to add on:
DUPLICATE_HIERARCHY_DEPTH information can be find in below:
While Synchronizer Identification “Off” is only needed only when you spot the targeted register is in CDC mode.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I need a couple of days to try out these steps.
Also, I would be really grateful if you could share the tips on reducing IC and cell delay for clock signals.
IC and Cell delay for RTL is modifiable through HDL changes but I don't think it is possible for clock signals to be done that way. If a dedicated clock resource on FPGA (a corresponding PIN) is properly chosen, I see a very zig zag path in the chip planner which ultimately increases the overall clock arrival delay at a node. Also, could you throw some light on PLL compensation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How much clock skew that you are looking at? If the skew is low, I wouldn't probably want to focus on clock.
In any case, Quartus have different clock region to try with for Arria 10 devices:
https://www.intel.com/content/www/us/en/docs/programmable/683461/current/clock-networks.html
While for PLL setting, I remember the direct compensation mode is the best for timing closure. But you may need to try out for your own design. Here is the reference: https://www.intel.com/content/www/us/en/docs/programmable/683461/current/clock-feedback-modes.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure if you need to take long to work on this? If yes, I will sign-off first and we can discuss more when you have more result from your end.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Noted, if you have a follow up question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page