Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎03-27-2021

How to get timing delay of each stage

Hi guys, I implemented a RISC32 5-stage pipeline which is IF, ID, EX ,MEM and WB stages. How to get the timing delay of each stage?

0 Kudos
3 Replies
Registered: ‎07-09-2009

Thats an easy one 

a) Decide what design language you want  to use

b) Learn that language

c) learn how to impliment the RISC

d) learn how to simulate 

e) Constrain the design

f) read the timing report to check you meet requirements, 

g) you are done

good luck 

   any questions on any of these, start a new post on a particular problem 

      As a tip, give a much info on what you have tried, OS your using, what v of the tools in any new posts


Good luck


<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Registered: ‎07-09-2009


If this answer comes from thr HLS report,  the easy "answer" is because it can.


As far as I can see , HLS does very little if any optimisation , leaving that to the synthesiser,


<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Registered: ‎01-23-2009

So, first, be aware that you can't meaningfully do what you are asking (at least not easily). When you implement a design, the tools work to make the design meet the timing constraints you have applied. For the heart of a RISC machine mostly the only thing that matters is the clock period (create_clock). The tools will then work to make sure that each static timing path within the design meets its requirement; again, translated to your RISC machine, this means that each pipeline stage operates at or under the clock period you have requested. Once this is accomplished, the tools will not optimize timing any further, they will optimize area and power, and then complete. So, if you RISC is properly designed, all 5 stages will have a slack of 0; all pipeline stages will be optimized to exactly meet your requested clock period.

If you increase the clock period to the point that you get failures, you will be able to find the timing of your worst pipeline stage - the one that fails. As for the other pipeline stages, it isn't clear that they, too, will be optimized for as fast as they can go - as far as the tool is concerned once it does the most optimization it can for the worst failing paths, there is little value in optimizing other paths that violate by less than the worst one; but Vivado doesn't clearly state what it will do in this case - it may still optimize them in order to reduce the total negative slack (even though it has no effect on worst negative slack). However, it is still clear that any pipeline stage that has a non-negative slack is not necessarily "the fastest it can be".

So all this to say that, to start, you need to over-constrain your design - ask it to meet an unreasonable frequency so that all pipeline stages fail timing.

Once you have done that, the default reports from the tool will give you a listing of the worst failing paths. You can control the number of paths you get (-max_paths) and how many paths to each endpoing (-nworst), but they are always listed in order of worst failing path. So if one pipeline stage has 1000 failing paths, then you won't see the next pipeline stage until the 1001st report. 

So you have to ask it manually.

The report_timing command is very flexible. Among its other options you have the -from and -to options, which limit the paths it is reporting to paths that start at the specified -from end end at the specified -to. For simplicity, it is easiest to specify these as the clocked cells you are interested...

So, if you create lists for 

  • all the flip-flops before your first stage - lets call it $stage0 (maybe not needed - see below)
  • all the flip-flops between your first and second stage ($stage1)
  • ...
  • all the flip-flops after your last stage ($stage5)

Now you can do customized reports

You could specifically restrict them to the paths between stages using a command like

report_timing -max_paths 100 -nworst 100 -delay_type min_max -from $stage0 -to $stage1 -name stage1

But this might be to limiting; there may be paths from control registers or feedback that affect a stage, so it is probably safer to just report the paths that end at a given stage regardless of where they start - this is done by not specifying a -start

report_timing -max_paths 100 -nworst 100 -delay_type min_max -to $stage1 -name stage1

You can do this for each stage.

Now how to construct your variables for the stage - these will use the get_cells command, but it will be up to you to correctly identify the flip-flops in each stage. 

set stage1 [get_cells {this_flop_reg* that_flop_reg* the_other_flop_reg*}]

If you REALLY want to know how fast each then you can create a separate design (a new project) for each pipeline stage and synthesize them separately and find out how fast they go - but that's a lot of effort.