| Author |
Message |
Mahzad
Joined: 25 Aug 2008 Posts: 3
|
25 Aug 2008 16:17 Delay calculations in Prime Time |
|
|
|
Does any body know;
1. If it's possible to get rid of black boxes, if yes how?
2. How to calculate the maximum delay of entire circuit?
Thanks.
|
|
| Back to top |
|
 |
jbeniston
Joined: 05 May 2005 Posts: 85 Helped: 8
|
26 Aug 2008 18:18 Re: Delay calculations in Prime Time |
|
|
|
| Mahzad wrote: |
Does any body know;
1. If it's possible to get rid of black boxes, if yes how?
|
Provide a timing library for the cells that don't currently have them.
| Mahzad wrote: |
Does any body know;
2. How to calculate the maximum delay of entire circuit?
|
report_timing -from -to ?
|
|
| Back to top |
|
 |
Mahzad
Joined: 25 Aug 2008 Posts: 3
|
26 Aug 2008 18:36 Re: Delay calculations in Prime Time |
|
|
|
Hi,
I already had solved the first one by coping link libraries from .synopsys_dc.setup file to .synopsys_pt.setup.
About the second one, I don't want to sepcify one particular timing arc. I need prime time to examin different timing paths and specify the worst delay, but report_timing and report_delay_calculation don't work this way. I'm still working on it.
Thanks any way.
|
|
| Back to top |
|
 |
raju3295
Joined: 04 Jan 2007 Posts: 77 Helped: 2
|
27 Aug 2008 8:00 Delay calculations in Prime Time |
|
|
|
| one thing i can suggest is to create the path groups and then do the timing analysis to get the timing information in the different paths,,,, i mostly work with cadnece tools,,, am not sure how this will be wrking in PT
|
|
| Back to top |
|
 |
rjainv
Joined: 18 Feb 2007 Posts: 147 Helped: 14 Location: Bangalore, India
|
28 Aug 2008 22:20 Delay calculations in Prime Time |
|
|
|
Correctly define your clocks, constrain input/output delays, define clock relationships ( if some clock domains are async, then declare them as false paths).
Then just do a "report_timing" without any arguments. It would print the top violators in each of the clock domain. It would make sense to group inputs and outputs into separate path groups based on their clock domain, otherwise they would clutter your flop to flop path reports.
|
|
| Back to top |
|
 |
Mahzad
Joined: 25 Aug 2008 Posts: 3
|
28 Aug 2008 22:38 Re: Delay calculations in Prime Time |
|
|
|
I have tried this, but the design is asynchronous. Most of the circuit works in one clock cycle, but there is one component which requires a variable number of clock cycles to complete. There are also some other combinatorial componenets. Therefore, the final output component is not clocked. Maybe this makes the trouble.
Tanks any way.
|
|
| Back to top |
|
 |
rjainv
Joined: 18 Feb 2007 Posts: 147 Helped: 14 Location: Bangalore, India
|
29 Aug 2008 5:44 Re: Delay calculations in Prime Time |
|
|
|
| Mahzad wrote: |
I have tried this, but the design is asynchronous. Most of the circuit works in one clock cycle, but there is one component which requires a variable number of clock cycles to complete. There are also some other combinatorial componenets. Therefore, the final output component is not clocked. Maybe this makes the trouble.
Tanks any way. |
1. If design is asynchronous, then you are picking up wrong tool. I am assuming design is synchronous, and you either had a typo or are getting confused.
2. Primetime be default assumes all paths to be single cycle paths. If you have flop to flop paths which have been designed to work in multiple cycles, then use primetime command to set that constraint. I think the Primetime command is 'set_multicycle_path' or something similar. 'help *multi*' should get you to the right command.
3. What you are saying by output component being not clocked is common. You need to give right set_output_delay for this output pin/port with respect to correct clock.
|
|
| Back to top |
|
 |