- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear All,
I am running the timing analyzer on my design and it reports slack on a path which looks like a "unintentionally" feedback path. And there are more like these. Device is a cycloneII EP2C20. SW used is Quartus II version 11. ; -15.651 ns ; reg_cen_rstn:u_alu_sign|q ; reg_cen_rstn:u_alu_sign|q ; clk ; clk ; best regards SimonLink Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Launch TimeQuest and run report_timing on the path to get details. Once you know what the path goes through, you can either change the code so it doesn't exist or do a set_false_path assignment to tell TimeQuest not to analyze it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Once you know what the path goes through, you can either change the code so it doesn't exist or do a set_false_path assignment to tell TimeQuest not to analyze it. --- Quote End --- I have tried : 1. analyze the path and found a large ripple carry path and ignored it for the wrong reason 2. to set a max delay for the path. This did not help. 3. to change the code by adding additional pipelining registers to the control path. It did not help. Coming back to point 1. I ignored this one cause I tought that the used Carry look ahead adder (with 196 LE's) was not so dramatic in size as the LPM_ADD_SUB (96 LE's) Well in timing it does matter. The LE's for the LPM_ADD_SUB are put in arithmetic mode and implements a Full Adder. I have gone from -15 ns slack to +2.5 ns. best regards Simon

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page