critical path and IC delay

Yes my design is "spread", basically it is composed of 180 parallel functional units, each take data to M9Ks (simple dual port) and the outputs are shuffle to the others FU memories by a large barrel shifter ( 180 per 8bits) ... .memories addressing is shared and controlled by a global controller

--- Quote Start ---

Routing is very, very seldom the problem. That doesn't mean it's not a large part, but the placement is usually the culprit. For obvious reasons, a spread out placement will cause long routes. (And to be honest, a spread placement is usually caused by a spread design, i.e. something like a mux that might feed multiple components in a device).

Can you list the path details of placement and routing(from TimeQuest, do report_timing with the -file "file.txt" option), or make your own if using TAN. Also, right-click on the path in TimeQuest, Locate -> Chip Planner, and then click the Expand button to see the actual routing. I'm curious if it's pretty much the Manhattan Distance, or pretty close. (Again, routing is almost always good, which is why this is strange). That's at least a good starting point...

--- Quote End ---

For Rysc =>

here the report_timing file , this design has been routed with the speed option and the result is worst than with the balanced option ....

--- Quote Start ---

Routing is very, very seldom the problem. That doesn't mean it's not a large part, but the placement is usually the culprit. For obvious reasons, a spread out placement will cause long routes. (And to be honest, a spread placement is usually caused by a spread design, i.e. something like a mux that might feed multiple components in a device).

Can you list the path details of placement and routing(from TimeQuest, do report_timing with the -file "file.txt" option), or make your own if using TAN. Also, right-click on the path in TimeQuest, Locate -> Chip Planner, and then click the Expand button to see the actual routing. I'm curious if it's pretty much the Manhattan Distance, or pretty close. (Again, routing is almost always good, which is why this is strange). That's at least a good starting point...

--- Quote End ---

fb_35,

The following line in the report caught my attention:

>>; 3.515 ; 0.000 ; FF ; CELL ; 1164 ; FF_X67_Y52_N1 ; in_mode_init~DUPLICATE|q

Here is a Flipflop that is driving 1164 nodes. Can you try splitting (duplicating that logic)? Or is that already a duplicated flop?

hello sw181,

this signal seems to be already duplicated as the original name is only in_mode_init .

my design is composed of 180 fu, in each fu this signal is used to select an operation mode, so this signal is used by the 180 fu and it appears that quartus has some difficulties to handle that ...

any advices to limit this fanout ?

thanks

Just a note on your barrel shift register(180 x 8):

Have you implemented that in logic or memory? If logic it will need 1440 flips at least. This can cause congestion. I will prefer memory implemented shift

=> kaz

yes the barrel shifter uses logic, how can I use memory for that ?

You can instantiate a ram based shift register megafunction. There are some restrictions but you can set the depth/width and taps as neccessary.

look at this thread and others similar

http://alteraforum.com/forum/showthread.php?t=5075&highlight=shift+register

--- Quote Start ---

hello sw181,

this signal seems to be already duplicated as the original name is only in_mode_init .

--- Quote End ---

did you duplicate it or did the tool? try enabling more of the physical synthesis options.

--- Quote Start ---

did you duplicate it or did the tool? try enabling more of the physical synthesis options.

--- Quote End ---

the duplication has been made by quartus,

a lot of critical paths in my design are due to signals with high fanout like this one