February 08, 2013

Puzzle: Fixing Timing Violation

Timing Violation can manifest due to a plethora of reasons. And it is important for an STA Engineer to understand the violating path and model the constraints properly before providing them to the Synthesis/PnR tools for optimization. Unnecessary optimization should be avoided because:
  • To save on the die area;
  • To save on the leakage power;
  • To prevent unnecessary congestion.
The figure below shows a scenario. Assume the clock period to be 8ns and the setup time of the capture flop (here, FF3) be 0ns and the clock-to-Q delay of the launch flops (here, FF1 & FF2) be 0ns. The violating path is shown in the figure. The negative slack is 1ns. 



How would you fix the above violation? Please note that there are many possible solutions; but one only solution adheres to the above discussed constraints of leakage power, area and congestion.

6 comments:

  1. Is this really a violation? -- or the path shown is logically false?

    ReplyDelete
  2. Assuming the two muxes have the same control polarity, this may not be real path but the timing engine does not know that. I am not sure how exactly to tell it to the timing engine but most probably two modes with mux case condition where the value of the port is set to 0 & 1 separately would work.

    ReplyDelete
  3. Yes! You are absolutely right! The path is logically false. And that is exactly the way one would tell the timing engine by making two separate modes for each value at the port.
    However, in complex SoCs, there are many modes: Functional, At-Speed, Stuck-At, Shift, LBIST-Atspeed, LBIST Shift, LBIST Stuck-At, MBIST and so on. And very often does the timing team tend to merge similar modes. Like Functional and MBIST. And so on. In those cases, it is sometimes expedient to put a false path rather than create a separate mode. The final call lies with the timing team!

    Thanks for the answer! :)

    ReplyDelete
  4. Both the input to last MuX are same, so that doesn't serve any purpose.

    ReplyDelete
  5. Hi Avinash.

    Not really! Both inputs appear to be same, but notice that they both go into different combo clouds, and hence the signal arriving at D0 & D1 of second MUX are different. Did you get my point?

    ReplyDelete
  6. I didn't understand it.Can u explain timing engine and 2 separate modes at each value at port?

    ReplyDelete