( ESNUG 299 Item 9 ) ---------------------------------------------- [9/21/98]
From: Gregg Lahti <glahti@sedona.intel.com>
Subject: ( ESNUG 297 #8 ) IPO -- Messy Equivalents When I Wanted Buffering!
> Anyone know how to get Synopsys *not* to change the cell-type during an
> -in_place optimziation compile (98.02-2)? Specifically, it will change
> functional equivalents like the following:
>
> from Z = !(A*B!)
>
> to Z = (A + B!) ( with nets to A & B swapped )
>
> (Yes, it's convoluted but they ARE functional equivalents if you think it
> out -- but this really isn't what I had in mind.) I was intending to
> freeze the netlist & layout and just add buffering or swap out cells with
> higher/lower drive to meet the min/hold design rules. I had everything
> defaulted except "compile_ok_to_buffer_during_inplace_opt = true". In the
> case above, DC decided that the funky NAND (for lack of a better term) was
> slower than the other and swapped the cell rather than add a buffer. Size
> of the cells were identical, but the input net connections got reversed in
> the process and not reported in the change log.
>
> Of course, this blows the LVS checks.
>
> Also, anyone else not really happy with the change log contents?
>
> - Gregg D. Lahti
> Intel Corporation
From: Gregg Lahti <glahti@sedona.ch.intel.com>
John,
I figured out the problem once my AE sent a quick blurb on the two variables
that cause cell swapping. However, this still brings up the change log
inadequecies. Here's our thread so far...
- Gregg Lahti
Intel
My AE at Synopsys said:
Can you double check the settings of the following vars just before
you hit "compile -in_place" ?
compile_ignore_area_during_inplace_opt
compile_ignore_footprint_during_inplace_opt
By default, these vars are false and should force all swaps cells to
match footprint, pin names, pin count, cell area and logic function.
If set false and all the above criteria are met, then the cell swap
can take place.
If however, these vars get set to true, it will enable DC to swap
cells based on function alone (or so the documentation says). Let me
know what you find - if at least one of these vars is not set to TRUE
and the above criteria are not all met, then this sounds like a bug.
You probably already know - but just in case - There are many variables
that control the IPO opto within compile and reoptimize_design. You can
get a list of these using "list -var links_to_layout" within dc_shell.
let me know what you find,
---- ---- ---- ---- ---- ---- ----
I let him know with the following:
Thanks for the call. I checked these variables:
compile_ignore_area_during_inplace_opt
compile_ignore_footprint_during_inplace_opt
Both of these variables were set to true by default when I start up
dc_shell (and when I load in our environment setup). I think I found
the culprit that allowed it -- our dso_synopsys_dc_setup.scr was
setting them. I read the man pages on it, and assume (wrong) that
they were default set to false but never checked it.
Our script has been changed to protect us from more evil transgressions.
;^)
However, that doesn't solve the end solution of the change log
generation- dc_shell just doesn't provide the needed info when it does
do the logic function swap (ie the input pin nets were swapped). We
could have handled the cell swap much easier if the change log
generated by the IPO had stated that the input nets were swapped as
well as provided info on the buffer tree insertion points. It seems
to me that dc_shell was poorly equipped to handle the reporting of the IPO.
- Gregg
---- ---- ---- ---- ---- ---- ----
And then he returned with:
Gregg, glad you found the culprit. You're right, I didn't mention the
change_list file pblm. This list will include any new cells or new nets.
It probably gave no indication of net swap because a new net was not
created, but nonetheless I can see how this could cause potential pblms
with netcompare.
Sounds like a good time for an enhancment request. I don't suppose you
can prune a small testcase for this - can you? Perhaps I can help -
being that you're pretty busy right now.
I'd like to touch base on the clock tree insertion issue you raised as
well. Let's touch base Monday.
TGIF
And we're still working on the clock tree issue now.
- Gregg Lahti
Intel
|
|
