Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Difference between combinational path delay and minimum period

Status
Not open for further replies.

rafimiet

Member level 5
Joined
May 21, 2015
Messages
94
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
2,364
After synthesizing, I get the static timing report as follows
Code:
   Minimum period: 7.577ns (Maximum Frequency: 131.987MHz)
   Minimum input arrival time before clock: 2.325ns
   Maximum output required time after clock: 2.826ns
   Maximum combinational path delay: 3.189ns
I am using Finite State Machine of over 600 lines. Throughout the code I have tried my level best to minimize the combinational path delay using registers wherever required. Now I have a combinational delay of 3.189ns, which is acceptable. Can I know what delays are taken into consideration when calculating minimum period? Is there anything that I can do to increase the Maximum Frequency of my design? (So far I have not provided any constraints to the clock)
 

The maximum period will be a sum of the worst case setup and hold time in the design, which will be the combinarial path plus some of the input/output required times.
To improve FMax, you need to reduce the combinatorial path delays. You can uses timing analysis to find out where the worst case paths are, and modify the code to improve the pipelining.
Basically - less logic between registers = higher fmax.
 

There are a few possible issues:

1.) Clock to out time of the source. This comes up in RAMs and shift-registers in some cases. Sometimes in other hard-ip. This is also important for IO. Many FPGA designs will use the IO registers in addition to one or more routing registers if desired.
2.) Combinatorial logic. This gets harder to estimate as clock rate decreases and allowed complexity greatly increases. Put another way, it is easy to estimate if logic might run at 500MHz but difficulty to estimate if something is so complex it would not run at 100MHz.
3.) Routing delays. This is the delays in connections between logic elements. In some cases this is due to physical constraints -- for example, routing to IO pins means the logic must be somewhat near that IO.
4.) Congestion. This is related to the above -- in this case, the logic could work much faster, but some elements are placed too far apart. This is a case where routing delays could be lower in a smaller design. In some cases, this can be fixed by more efficient use of BRAM/DMEM/etc...

IIRC, you should also provide a clock constraint. I forget if the tools will take too much effort to optimize your design otherwise.
 

IIRC, you should also provide a clock constraint. I forget if the tools will take too much effort to optimize your design otherwise.

It can be a good idea. At least with Quartus, with no constraints it assumes a 1GHz clock. An overconstraint like this can cause the fitter to give up early as it will never meet timing and might actually give you worse result than you would get with a realistic constraint.
Its good for initial FMax on a single block, but should never be used for a final design.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top