( ESNUG 215 Item 3 ) ---------------------------------------------- [4/20/95]
Subject: (ESNUG 213 #1 214 #3) "DC 3.2a vs. 3.0b - Smaller But Slower Designs?"
>> Design Compiler 3.0b Design Compiler 3.2a
>> -------------------- --------------------
>> Combinational area: 39,936.000 38,893.750
>> Noncombinational area: 27,637.250 27,714.250
> |
> got larger noncomb area here ---'
>
>I have a little problem with the above results, and that's basically the
>noncomb logic area has increased. More info is needed here to explain this
>increase: is it because Synopsys simply synthesized different cells (i.e.
>buffered FF, etc... ) -- or is it because there are unknown additional FF
>and/or latches??? I've encountered a few cases where the same HDL code and
From: prz@hprnd.rose.hp.com (Paul Zimmer)
John, I checked: there are the same number of flops/latches. I did notice
one block where 3.0b used a particular presetable flop and tied the preset
inactive while 3.2a did not do this. Also, the difference in area
(comb/non-comb/combined) is about 3/10 of one percent...
> Path Group A's slack: 8.18 8.17
> Path Group B's slack: ***? -3.96
> Path Group C's slack: -1.58 -2.05
>
> ***? - This path group came up in 3.0b but report_constraint -verbose
> wouldn't give me any "slack" information. Same script, source,
> and constraint files. Very strange.
Here's more data on this "missing constraint" in 3.0b. I have since seen
this in another context. I compiled a block (using lots of tricks like:
group paths, balance registers, etc) in 3.0b and wrote out the .db file.
When I pull this .db file back into 3.0b and report a particular path,
it says the path is "unconstrained".
When I pull this SAME .db file (generated by 3.0b) into 3.2a and report
the SAME path, it shows the proper constraint!
(Yes, you got that right -- 3.2a finds a constraint in a 3.0b database file
the 3.0b can't find!) Very strange.
Besides this oddity, I'm starting to feel more comfortable with 3.2a now.
- Paul Zimmer
Hewlett Packard, Roseville
|
|
