Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

A timing closure problem.

I have suffered a timing closure problem. I use the Arria II GX device and Quartus 10.1 without SP . In my design , I use the DSPBuilder ADV Block create a IP. In the IP , after the inputs pass through some combinational units , they'll generate some adress for lookup RAM.After I have integrated the IP into the system and implemented it , the TimeQuest shows that the timing failed . The report shows the statistics of the failing path like the attatching figure.

After exploring the report , I find the falling timing happens beteew the IP's input registers and the RAM's address registers

I find that the data's IC has a not too big percentage. So I think I can solve the timing through tuning the Quartus environment. But after trying all kinds of setting that the timing advisor recommend, the result is the same. The next step I tried is create a partition and a logiclock for the IP and make the other part of the design as empty partition.The logiclock's location and size are floating and auto. After this , I get the same result and the chip editor shows that the fitting result as the attaching figure.

The result shows that the place of the componets on the critical path is'not optimized. After tried to change the size of the logiclock , the result is the same. At the same time , I notice the IP's input registers fan out is 23. I tried to constrain them to 1 . The result improved , but still have some failling results.

After all these tries , I feel frustrated. It seems the options and floorplan technich Quartus provides isn't working. Please help me find some ways to improve the IC delay , thanks.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I have fixed this problem by inserting one level register before the IP's input register and applying retiming for them. But I just need some help for me to master how to use the options and the logiclock technich of Quartus to improve the IC type timing performance. Thanks.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    - This is generally beyond the means of LogicLock, i.e. everything is actually pretty close, and putting a fence around it won't make it much tighter.

    - In generaly don't do auto/floating LLRs. It's actually fine for what you did, but it's recommended to make them fixed size/locked pretty soon. The fitter does a better job with fix/locked. (Think of floating/auto as giant battleships the fitter moves around. Anytime it moves on, it has tons of logic that it has to clear out to make way, which disrupts everything.

    - Can you show the data arrival path? Just curious what it looks like. Note that this is what critical paths look like. There are probably thousands of paths like this, and the fitter won't get them perfect. Also, each level of combinatorial logic generally has a number of fan-ins. Let's say that it's 4 nodes into each level. It's impossible to place all of those into the same LAB, and you end up with all these hops. Basically, if I see a critical path like that I generally don't expect more out of the fitter and look at other things(like the pipelining you did). One thing is to run "report_timing -npaths 200 -setup -to destination_register_name -panel_name "many paths"", where you change the destination_register_name to the destination of the critical path. Often you'll see 50 or more different paths all zigzagging through those labs to reach the final one. When you look at the worst one in that context, it sometimes makes more sense. (DSP designs tend to have less wide combinatorial logic than general designs, so not positive...)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The figure give the data arrival path with the worst slack. Based on your suggestion , I explored my design and found the fan in to the combinational block is not too much. But after using the command your suggested to analyze the failing path. I found that there are too much intermediate nodes for the failing path. These nodes need a lot of lcell to fit , and will make the path between source and destination go through several LAB , and not a LAB. Thanks , Rysc.