Say I have 3 modules: 1) Top module 2) sub-module A-(achieved freq 150Mhz when compiled separately) 3) sub-module B-(achieved freq 200 Mhz when compiled separately) After I instantiate sub-modules A and B in top module , I am getting 80Mhz and 110 Mhz from both respectively. So , I thought if I retain the same fitter placement of module B (applying logic lock and design partitioning), I can get same frequency i.e, around 200 Mhz on the Top module . But without any luck frequency is dropping. Please note : Code is optimised as much as possible. I tried to look at the timing analyzer critical paths. These paths had high critical paths , timing closure recomendations was asking me to reduce the combinational path. But number of combinational path was just 1 like a signal assignment a<= b; It is not possible to break this path . My question is why is the same path which was achieving high frequency while compiling a sub module independently, became a critical path at the top level compilation? Is it because top level logic is huge(>75% of available resource) so that fitter became inefficient? So, please suggest me how to solve this issue. I want to achieve close to same max frequency 200 Mhz at the top level.

Do you have registers on the boundaries of your partitions? If you don't, then paths in the top level may become critical. Remember that there is no optimization across partition boundaries, so combinational logic on the boundaries of the design partitions cannot be optimized with respect to the top level. Adding registers at the boundaries can fix this, allowing you to run the design faster at the expense of an extra cycle of latency. #iwork4intel

Yes , all output signals from a submodule are registers.So before sending a signal to a other module , I am registering it .

Hi, Is the failing path within the sub-modules? Have you tried to preserve timing-closed partitions and use in the top design? Thanks. Best regards, KhaiY

Hi,1) if I don't preserve design partition (fitter netlist of a submodule ) then yes , there are some failing paths within the submodule. Few days back fitter used to fail because of high routing congestion . So, I changed the fitter effort to 8.0 , so fitter passes but with significant loss of timing .2) If I preserve design partition(fitter netlist of the submodule ), then I don't think I have any critical paths within sub-modules . But there is inbetween 2 sub-modules. Here I get this fitter error sometimes :Error (18999): Placement cannot find a legal solution.Error (170079): Cannot place node <name>of type MLAB cell.But after changing fitter effort settings to 8.0 . It will pass with loss in timing.3)what does preserve timing closed partition mean ? Is it same as preserving fitter netlist in design partition? If yes , then yes I have done as in 2nd point

Hi,What is your interconnect usage? Designs with an average value below 50% typically do not have any problems with routing. Designs with an average between 50-65% may have difficulty routing. Designs with an average over 65% typically have difficulty meeting timing unless the RTL tolerates a highly utilized chip. Peak values at or above 90% are likely to have problems with timing closure; a 100% peak value indicates that all routing in an area of the device has been used, so there is a high possibility of degradation in timing performance.Thanks.Best regards,KhaiY

Ways to improve timing on Top module? | Altera Community

11 Replies

sstrell
Super Contributor
6 years ago
Do you have registers on the boundaries of your partitions? If you don't, then paths in the top level may become critical. Remember that there is no optimization across partition boundaries, so combinational logic on the boundaries of the design partitions cannot be optimized with respect to the top level.

Adding registers at the boundaries can fix this, allowing you to run the design faster at the expense of an extra cycle of latency.

#iwork4intel
- Yogesh
  Occasional Contributor
  6 years ago
  Yes , all output signals from a submodule are registers.
  
  So before sending a signal to a other module , I am registering it .
  - KhaiChein_Y_Intel
    Regular Contributor
    6 years ago
    Hi,
    
    Is the failing path within the sub-modules? Have you tried to preserve timing-closed partitions and use in the top design?
    
    Thanks.
    
    Best regards,
    
    KhaiY
KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

What is your interconnect usage? Designs with an average value below 50% typically do not have any problems with routing. Designs with an average between 50-65% may have difficulty routing. Designs with an average over 65% typically have difficulty meeting timing unless the RTL tolerates a highly utilized chip. Peak values at or above 90% are likely to have problems with timing closure; a 100% peak value indicates that all routing in an area of the device has been used, so there is a high possibility of degradation in timing performance.

Thanks.
Best regards,
KhaiY
- Yogesh
  Occasional Contributor
  6 years ago
  find the interconnect usage as below:
  
  Average interconnect usage (total/H/V) 50.7% / 48.7% / 57.0%
  Peak interconnect usage (total/H/V) 80.4% / 81.7% / 86.1%
- Yogesh
  Occasional Contributor
  6 years ago
  Hi Khai,
  
  Average interconnect usage (total/H/V) 50.7% / 48.7% / 57.0%
  Peak interconnect usage (total/H/V) 80.4% / 81.7% / 86.1%
  Since average interconnect is less it should not cause any problems in routing right ?
  But 8 out of 10 times fitter terminates because of routing congestion.
  Is there a way to find which module has high interconnect usage ? So that I can change the coding style and improve timing .
  - KhaiChein_Y_Intel
    Regular Contributor
    6 years ago
    Hi Yogesh,
    
    Yes. There is a way to check which module uses most of the routing resources.
    
    Thanks.
    
    Best regards,
    
    KhaiY

Forum Discussion

Ways to improve timing on Top module?

11 Replies

Recent Discussions

USB-Blaster II malfunction

License 6AF7_0186 for University Program

USB Blaster III and Cyclone III

Unable to configure new license server

ModelSim Intel FPGA Ed. 2020.1 not updating changes to HDL File