( ESNUG 306 Item 7 ) ---------------------------------------------- [12/3/98]
Subject: (ESNUG 305 #6) DC Won't Buffer Module Outputs W/ Bottom-Up Approach
> We are using a bottom up synthesis approach for a chip that we are doing
> with LSI. On our critical paths dc is leaving ***A drive parts on the
> outputs when all the cells in the paths up to the output have C and D
> drive. We are using
>
> set_load load_of (lcbg10pv/BUFA/A) * 5.0 all_outputs();
>
> which might be a little weak for nets that are enclosed by a much larger
> wireload model, BUT even at the lowest compile level the last
> incremental delay is the largest in the path because dc won't upgrade
> from an A drive cell at the output! And these are paths that don't meet
> their constraints at the lowest levels! Why won't dc increase the drive
> strength of our output cells?
>
> - Greg Brookshire
> Peracom Cary, NC
From: Don Devine <devine@Cadence.COM>
John,
I had a similar problem to this in the past. In my case I had clock which
drove some flip flops AND some combo logic, at a lower level, and after a
series of gates became the clock for another flip flop (ugly I know).
When I did a compile at the top level I had DRC errors. Obviously I wanted
to remove any anomalies, so I performed another compile but it was to of no
avail.
Anyway, I found the problem arose in the COMBO path which was driven by
the clock at top level. This occured because I had placed a
'set_dont_touch_network' on the clock signal and this prevented DC from
changing the cells 'on this combo clock network' from being changed. I was
using 1997.08 at the time, so as I'm not an expert with the latest versions,
I don't know if this can be avoided.
The workaround I had to do was to break the signal path to the sub block
and thus with the different clcock name 'combo_clock' and not defined as
a clock, the 'combo_clock & set_dont_touch_network problem' was no more.
- Don Devine
Accent S.r.l Vimercate, ITALY
|
|
