Potential Problem: Finding the critical Path @ Timing Report

[gathanas]

Hi everyone,

I have a really simple design, which includes a MUX2to1, a XOR gate tree with 3 XOR gates, and 2 adders, all connected in a row. This is actually the theoritical critical path of a bigger design of mine. At the start of the row, as well as the end, there are registers, so the ISE (XST) can compute the operational freq. I think that the critical path of this small design is actually the whole row (design). But when i synthesize it (XST) the result show that:

"  Timing Summary:
    ---------------
     Speed Grade: -6

    Minimum period: 5.201ns (Maximum Frequency: 192.271MHz)
    Minimum input arrival time before clock: 5.836ns
    Maximum output required time after clock: 4.575ns
    Maximum combinational path delay: No path found"

and

"  =========================================================================
Timing constraint: Default period analysis for Clock 'clk'
  Clock period: 5.201ns (frequency: 192.271MHz)
  Total number of paths / destination ports: 7204 / 32
-------------------------------------------------------------------------
Delay:               5.201ns (Levels of Logic = 32)
  Source:            reg_in/bout_2 (FF)
  Destination:       reg_out/aout_31 (FF)
  Source Clock:      clk rising
  Destination Clock: clk rising

  Data Path: reg_in/bout_2 to reg_out/aout_31
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDCE:C->Q             2   0.449   0.684  reg_in/bout_2 (reg_in/bout_2)
     LUT3_L:I1->LO         1   0.347   0.132  ADDER2/Madd_cC1311 (ADDER2/Madd_cC1_bdd3)
     LUT4:I3->O            1   0.347   0.410  ADDER2/Madd_cC1111 (ADDER2/Madd_cC1)
     LUT4:I2->O            1   0.347   0.000  ADDER2/Madd_c_Madd_lut<3> (ADDER2/Madd_c_Madd_lut<3>)
     MUXCY:S->O            1   0.235   0.000  ADDER2/Madd_c_Madd_cy<3> (ADDER2/Madd_c_Madd_cy<3>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<4> (ADDER2/Madd_c_Madd_cy<4>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<5> (ADDER2/Madd_c_Madd_cy<5>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<6> (ADDER2/Madd_c_Madd_cy<6>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<7> (ADDER2/Madd_c_Madd_cy<7>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<8> (ADDER2/Madd_c_Madd_cy<8>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<9> (ADDER2/Madd_c_Madd_cy<9>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<10> (ADDER2/Madd_c_Madd_cy<10>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<11> (ADDER2/Madd_c_Madd_cy<11>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<12> (ADDER2/Madd_c_Madd_cy<12>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<13> (ADDER2/Madd_c_Madd_cy<13>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<14> (ADDER2/Madd_c_Madd_cy<14>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<15> (ADDER2/Madd_c_Madd_cy<15>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<16> (ADDER2/Madd_c_Madd_cy<16>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<17> (ADDER2/Madd_c_Madd_cy<17>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<18> (ADDER2/Madd_c_Madd_cy<18>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<19> (ADDER2/Madd_c_Madd_cy<19>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<20> (ADDER2/Madd_c_Madd_cy<20>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<21> (ADDER2/Madd_c_Madd_cy<21>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<22> (ADDER2/Madd_c_Madd_cy<22>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<23> (ADDER2/Madd_c_Madd_cy<23>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<24> (ADDER2/Madd_c_Madd_cy<24>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<25> (ADDER2/Madd_c_Madd_cy<25>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<26> (ADDER2/Madd_c_Madd_cy<26>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<27> (ADDER2/Madd_c_Madd_cy<27>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<28> (ADDER2/Madd_c_Madd_cy<28>)
     MUXCY:CI->O           1   0.042   0.000  ADDER2/Madd_c_Madd_cy<29> (ADDER2/Madd_c_Madd_cy<29>)
     MUXCY:CI->O           0   0.042   0.000  ADDER2/Madd_c_Madd_cy<30> (ADDER2/Madd_c_Madd_cy<30>)
     XORCY:CI->O           1   0.824   0.000  ADDER2/Madd_c_Madd_xor<31> (temp4<31>)
     FDCE:D                    0.293          reg_out/aout_31
    ----------------------------------------
    Total                      5.201ns (3.976ns logic, 1.225ns route)
                                       (76.4% logic, 23.6% route) "

Which show that the Critical Path is focused on the second adder of my design (ADDER2) and not at the whole design.

Is there anything else i should see or look at the report? My thought for the theoritical critical path seems to be wrong?

In general, how can I spot the critical path of my design with ISE (XST synthesizer) and compare it with the theoritical one, which appears at the block diagram of the design?

[eilert]

Hi,

you are right, your assumption about the critical path is wrong. :-)

What you mean is the longest path between input and output.

But that path may be meaningles for timing issues in synchronous designs.

The critical path is the path between two synchronous elements (FFs) that determines the maximum possible clock frequency.

 As you can see, your Path goes from FDCE:C->Q   (one FFs Output) to FDCE:D (another FFs input) andis calculated to have a delay of 5.201ns.

You find that very same number in the line with the minimum period information for the design: Minimum period: 5.201ns (Maximum Frequency: 192.271MHz)

So, if you find a way to minimize the delay of this path you can improve the maximum possible clock frequency.

Unless another path in your design becomes slower than this path. 

And so the story continues....

Have a nice synthesis

  Eilert

[gathanas]

Hello,

First of all, thanks a lot for the answer!

I totally agree with you as far as the critical path and the longest path.

The  FDCE:C->Q (the first FF) is the register I have in the beggining of the design (reg_in is the name of the port map) and the  FDCE:D is the register I have in the end of my design (reg_out is the name of the port map).

So, based on what you said (which is completely right), the critical path of my design starts an the start of my design and ends at the end.

But, the thing tha confuses me is this: why after the  FDCE:C->Q, there are signals (such us: LUT4:I2->O and MUXCY:S->O) which are for ADDER2 (which is my second adder (final component of the design) ? It shouldn't display the entire path, including signals to/from the other components of the path?

Thanks again,

gathanas           

Message Edited by gathanas on 04-15-2010 04:56 AM

[eilert]

hi gathanas,

if I understand you correctly you expected the combinatorical parts of ADDER2 to come after reg_out?

Well, maybe you designed it that way, but during synthesis and mapping logic and fliflops can be rearranged to improve timing issues. (register balancing, and other stuff)

So it may be quite OK to find after the implementation some logic between two register stages which you didn't have designed that way.

For a more qualified analysis you have to look at your design sources and compare them to the netlist. 

Take a look at the conbinatoric stuff that after reg_out in the netlist. Is that also part of the ADDER?

What kind of logic did you expect to be between these two FFs?

Check if the logic is now more equally distributed between your register stages than it was in your design sources.

You will probably find out that the tool did a lot of things. 

you may change the synthesis and map options to inhibit these optimisations and then compare the new timing result to the old one.

I would bet without these optimisations timing gets worse. :-)

Have a nice synthesis

  Eilert