( ESNUG 302 Item 7 ) --------------------------------------------- [10/21/98]
Subject: (ESNUG 301 #5) Synopsys Seems To Give Inconsistant Timing Reports?
> We are building a 500k gate chip with LSI. When we do top level timing
> reports we see may clk-to-q times of more than 3ns for nets with only a
> fanout of 2. We are using the "enclosed" mode for wireloading, but these
> nets are contained within small blocks. When we time the enclosing block
> the exact same nets have delays less than 0.5ns. (?) ...
>
> clock pad/clk (rise edge) 0.00 0.00
> clock network delay (ideal) 0.00 0.00
> core/atm/at_learn0/ln_fsm/sa_rd_req_reg/CP (FD2QC) 0.00 0.00 r
> core/atm/at_learn0/ln_fsm/sa_rd_req_reg/Q (FD2QC) 3.69 3.69 f ?
> core/atm/at_learn0/ln_fsm/sa_rd_req (net) 2 0.00 3.69 f
>
> - Greg Brookshire
> Peracom
From: Oren Rubinstein <oren@gigapixel.com>
John,
The classical cause for high CLK->Q delays is a slow transition on the
clock. This can happen when you forget to set_drive 0
In this case, it seems you're driving all the flops directly from the clock
input pad.
There should be a fake clock driver which lateer gets replaced by the clock
tree, or something like that, and the fake driver should have infinite
drive. If you don't have one of those, you can create it yourself:
module clk_drv(clk_in, clk_out);
input clk_in;
output clk_out;
parameter TREE_DELAY = 3.0; // Or whatever you think it will be
assign #TREE_DELAY clk_out = clk_in;
endmodule
Then, in the top level, you insert clk_drv in the clock, between the pad
and the flops, and you can do the following:
1. When you load the top level, make sure Synopsys can't see the fake
driver, so it treats it as a black box.
2. Do a create_clock on the clk_drv/clk_out pin, and
set_drive 0 clk_drv/clk_out
Hope this helps.
- Oren Rubinstein
GigaPixel Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@NPLab.Com>
John,
You might want to add -trans to your timing reporting and check to see if
the transition times are the cause for the difference. Another thing to
do, if your library allows it, is
report_delay_calculation -from
core/atm/at_learn0/ln_fsm/sa_rd_req_reg/CP
-to core/atm/at_learn0/ln_fsm/sa_rd_req_reg/Q
It will give you all the details of where it comes up with the delay
numbers.
One other item to look at is the loading on the net.
report_net -verbose -connections core/atm/at_learn0/ln_fsm/sa_rd_req
should provide that.
- Scott Evans
NeoParadigm Labs San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Bret Bersack <bret_bersack@mint-tech.com>
John,
We had a similar problem that was caused by the clock transistion time.
Even though the clock network was "ideal", the clock driver transition
time was being used! You can check this by adding the "-transition_time"
switch to the report_timing command.
The fix is: set_clock_transition 0.0 find(clock, "pad/clk");
- Bret Bersack
Mint Technology Billerica, MA
---- ---- ---- ---- ---- ---- ----
From: Ajoy Aswadhati <ajoy@lucidsolutions.com>
John,
It is likely that Greg forgot to specify set_drive of 0 (infinite drive) on
the clock port.
dc_shell> set_drive 0 clock
Assuming clock is a port on the module for which he is doing the timing
analysis.
If the drive strength of the clock port is not specified correctly the clock
signal will have large transition times because of the high fanout
associated with clock networks. This in turn is reflected in big delay seen
in the clock->q time for the flops connected to this clock port.
The command 'report_delay_calculation' can be used to figure out how the
delay values of timing arcs inside a cell are computed. If the 'clock'
signal is driven by a pad or buffer then the buffer or pad should have a
high drive strength specified.
- Ajoy Aswadhati
Lucid Solutions
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys CAE ]
Hi John,
Keep me anonymous, thanks.
The usual culprit for this is heavy loading on the clock net, not the
Q output of the register. The result is a large transition time on the CLK
pin, causing a large transition on the Q pin. The report_delay_calculation
-from CLK -to Q command should be of some help here. This is common in
pre-layout designs where you have a large fanout on the clock because you
haven't inserted clock buffers yet. If this is Greg's case, you can do a
set_clock_transition on the clock that will set the transition all along
the clock network. Set it to some reasonable expected value.
- [ A Synopsys CAE ]
---- ---- ---- ---- ---- ---- ----
From: Tom Cruz <tomcruz@us.ibm.com>
Hi Greg - did you try looking at the slew rate of the clock input to your
storage element (flip-flop to you - latch to me).
We had a similar problem on a previous chip - a timing report from the top
level of the chip showed a 5 ns clock to Q delay but when changing to a
lower level design we got the correct clock to Q delay.
In our case, the slew rate of the clock into the storage element was long
due to the lack of a clock tree. In other words, the clock root book was
driving too many loads.
- Tom Cruz
IBM Networking Hardware Division
---- ---- ---- ---- ---- ---- ----
From: Greg Brookshire <gbrookshire@peracom.com>
John,
We discovered our problem. Our synth person was running timing on the top
level of our chip which included pads and no clk tree. The set drive 0 of
course did not propagate through a pad cell like he thought it might so our
internal clk net had a horrible transition time which created the clk-q
times we saw. These ESNUG responses helped a lot.
- Greg Brookshire
Peracom Cary, NC
|
|
