ADMIN NOTE: I've just recieved in electronic form the names, business
addresses and e-mail addresses of this year's SNUG attendees from
Synopsys!
There seems to be roughly 300 names on this list, but not all of them
gave e-mail addresses, plus there's some overlap of names on the existing
list of subscribers to ESNUG and the SNUG attendees list.
My guess is that, after all that is said and done, this will probably
add another 75-100 readers to the present list of 500+ readers.
- John Cooley
( Post 54 Item # 1 ) --------------------------------------------------------------
From: jaa@SU59D.ess.harris.com (John Auer)
> Subject: ESNUG Posting Number 52 ( Item # 2 )
> From: Jay McDougal <jaym@hpcvcbu.cv.hp.com>
>
> Hello,
>
> I came across the following bug while trying to ungroup a hierarchical
> design that had children of children with dont_touch attributes.
>
> I was using ungroup -all -flat to remove the hierarchy but there were
> some cells in the hierarchy that I had compiled with dont_touches
> because I wanted them to use special Flip-Flops. When the design
> was flattened, the dont_touched modules were also flattened!!
>
> To get around this problem I had to call ungroup -all repeatedly
> until all the hierarchy was flat. This left the dont_touched modules
> intact!
According to the Synopsys online manual, ungroup behaves as
advertised, i.e., no bug. I agree its not very useful, though.
A "man ungroup" will reveal that dont_touch'ed cells are indeed
ungrouped, and the only solution is the one you indicated
(repetitive ungrouping).
Maybe you can talk Synopsys into adding a system variable to
alter the behavior of ungroup with hierarchical dont_touches?
Another approach would be to add a custom cell to your library, or create
a new library altogether. Synopsys seems to work well with multiple
libraries. An example of using them:
link_library = {normal_library.db custom_library.db}
target_library = {normal_library.db custom_library.db}
Possible problems: you can't make a library cell out of other
library cells, you'll need to know/learn Synopsys' library tools,
and you'll need to know the normal_library's area and time units
(area is sometimes in gates--sometimes its cell widths;
time/load may be based on normalized loads--not pF, etc.) These
should be deducible by examining cells in the normal_library.
Hope this helps.
John Auer
Harris GASD
( Post 54 Item # 2 ) --------------------------------------------------------------
From: cindy@ca45.zoran.hellnet.org (Cindy Eisner)
> CALL FOR DISCUSSION! CALL FOR DISCUSSION! CALL FOR DISCUSSION!
>
> - Are there ways to avoid getting into situations where you
> find yourself in an endless loop of iterating through
> recompiles, characterizings and such?
i have given up on characterize because of these endless loops. what has
worked best for us is to do each compile of sibling blocks separately, and
require the designer to spend an extra few minutes estimating the required
arrival times for input signals and the delay for output signals. the
estimations do not have to be precise - it is enough to say either beginning,
middle or end of clock period. then these estimations are updated in a
loop (synthesis, report, constraint update, synthesis, report, constraint
update, etc.) where the updating is done by hand. this is not as bad as
it sounds, since the constraints usually stabilize after no more than two
synthesis rounds. now, for every logic change, only one synthesis round
is required (because you have already determined the good constraints). while
if you had used characterize, you would have the compile-characterize endless
loop after every logic change.
one important point: when you synthesize this way, you must make sure that
the contraints you have given are consistent between the driving block and
the sampling block. otherwise the reports are garbage.
> - What gatecounts have you found that work best for submodule
> size? Where's the practical limit to when a design is too
> big to not synopsize heirarchically?
about 1000-1500 gates per compile works best for us, although we do have
some blocks with ~2000 gates. however, at this size, i frequently see
synopsys not solving max_transition (max_fanout) design rules which could
have been easily solved without hurting anything else.
Cindy Eisner
Zoran Microelectronics LTD
|
|
