( Post 68 Item 1 ) -------------------------------------------------------
From: fields@danube.acuson.com (Julian Fields, ASIC contractor)
> From: roberts@slc.unisys.com (Doug Roberts)
>
> We were able, with some effort, to createh and interconnect the
> busses in the Synopsys schematic editor (see my previous submission). We
> ran a successful simulation. Then when we went to create Mentor "do" files
> for the NetEd editor, the interface could not handle busses.
>
> So the schematics we ended up with in NetEd have huge symbols with many nets.
You're going: Synospys -> Neted.
Why not try: Neted -> netlist (or edif) -> Synopsys?
That way you could draw your schematic with "for loop" frames and busses.
( Post 68 Item 2 ) -------------------------------------------------------
From: paulc@oki.COM (Paul Chau)
What does the data in the flat timing report really mean ?
In the report_timing command, it has an option "-flat" to
display timing through the design hierarchy. If a signal
goes through the whole hierarchy, shouldn't the -flat option
provide the true timing delay info for each gate in its path?
In the case when the report was generated at the very top
level of the hierarchy, the report showed the critical path
from the input to the output ports. When the same report was
generated at a lower level of hierarchy, shouldn't the time delay for
each gate be the same ?
An example 'discrepency' in timing reports that I see are:
///*** this is for the upper level module *****//
design_analyzer> report_timing -path full -flat -delay max -max_paths 5
Max Delay
Point Type Fanout Path Incr
--------------------------------------------------------
Clock in 42 0.00 r 0.00
r2/q_reg[1]/q fd1a 5 3.49 f 3.49
mux4/U213/yn iv104 3 4.04 r 0.55
mux4/U188/yn nd204 5 5.13 f 1.09
mux4/U224/yn oai28a 2 8.42 r 3.29
add1/r44/U106/yn iv1 2 9.72 f 1.30
add1/r44/U163/yn nd204 8 10.47 r 0.75
add1/r44/U100/yn nd3 2 12.46 f 2.00
add1/r44/U98/yn nd402 3 13.70 r 1.24
add1/r44/U108/yn enr202 2 15.70 f 2.00
add1/r37/U88/yn nd302 1 16.55 r 0.84
add1/r37/U87/yn iv104 4 17.64 f 1.10
add1/r37/U93/y ad3 2 19.45 f 1.80
add1/r37/U74/yn mx2d 1 20.71 f 1.26
r32_ne_2/q_reg[6]/d
fdr1a 1 20.71 f 0.00
///*** this is for the lower level module *****//
design_analyzer> report_timing -path full -flat -delay max -max_paths 5
Max Delay
Point Type Fanout Path Incr
--------------------------------------------------------
b[2] in 2 0.00 f 0.00
r44/U106/yn iv1 2 1.22 r 1.22
r44/U163/yn nd204 8 2.45 f 1.24
r44/U100/yn nd3 2 3.65 r 1.20
r44/U98/yn nd402 3 5.86 f 2.21
r44/U108/yn enr202 2 7.86 f 2.00
r37/U88/yn nd302 1 8.70 r 0.84
r37/U87/yn iv104 4 9.80 f 1.10
r37/U93/y ad3 2 11.61 f 1.80
r37/U74/yn mx2d 1 12.81 f 1.20
sum[6] out 1 12.81 f 0.00
As shown in both report, signal going through the same series
of gates :
U106 -> U163 -> U100 -> U98 -> U108 -> U88 -> U87 -> U93 -> U74
has different time delay at the two levels. Which report is the true
static timing for the design? And what causes the discrepency ?
I have consulted Synopsys hotline about this problem, they
said the discrepency was caused by the difference in wire
load model specified at the two different levels. But the above
example has the same wire load model for both levels, and there is
still a difference in timings!
Thanks in advanced for all the comments and solutions.
paul chau
|
|
