Forum Discussion

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

Timing Closure, LogicLock and Incremental Compilation

Hi Folks,

I have some questions that I would like to bring up. I have a big project with lots of timing violations (IPs and user logic). My first goal now is to close the timing for the IPs and tweak the RTL of the user logic later on. So I am thinking of using LogicLock and Design Partitions. Here are some of my strategies and questions.

1) Setting most of the IPs to Empty and a few to post-synthesis and Top to Empty partitions and refit the IPs one by one, and once they meet timing, I will set it to post-fit and proceed to the next IP. However, from the timing analysis, I still see other non-IP modules failing timing. Aren't they supposed to be 'empty' and hence have no effect on the fitting/timing analysis?

2) Assigning these IPs to Logic Lock Regions and perform similar approach as step 1, however noticed that their timing is worse than those in step 1. Are there anything that I can do to improve the timing? Can I make the Logiclock Regions even larger but set the "Reserved" function to off so that other logic can make use of these regions as well?

So just assume might primary goal now is to close the timing of just the IPs, what other steps that I can take for this?

Thank you.

2 Replies

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

    Hi guys,

    There is something that I do not quite understand in design partitions. Let's say I have partitions for modules A, B and C where I am only interested in having a clean timing for A and B. So I set module A and B to 'Post-Synthesis' and module C to 'Empty'. However, after compilation, I can still locate the primitives of module C in Chip Planner and also in Timequest Timing report. Isn't this module supposed to be 'bypassed' since it was set to empty?

    Another question is that let's say I have A meeting timing now. So I now changed it to post-fit while B still at post-syn, hoping to preserve the timing of module A. After I re-fit the project, I notice that module A's timing got worse. This doesnt seem to match with the concept of Incremental Compilation where the results are preserved. Anything that could've done wrong?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    "Empty" partitions aren't fully emptied - Quartus will automatically preserve some logic in those partitions. Typically it will be periphery logic or logic connecting to the periphery so it shouldn't be a lot left over.

    Regarding timing failures in preserved modules - are all nodes along the path preserved? TimeQuest has an "Extra Fitter Information" tab that has a column indicating whether the node was locked or not and which partition the node belongs to. Often what is happening is that the source/dest are in the preserved partition but the combinational nodes along the path are in a partition that was previously "empty". In general, using this kind of "empty" flow requires some planning to avoid problems closing timing on cross partition paths later on (e.g. having registered partition boundaries helps a lot).