( ESNUG 296 Item 11 ) --------------------------------------------- [7/23/98]
Subject: (ESNUG 295 #6) 'Translate' W/ Buffering, dont_touch, & Incrementals
> We are attempting to translate a very large design from one technology to
> another similar one.
>
> Our first attempt was to load the big .db file in and let her rip. But the
> major sub-blocks have dont-touches, so it didn't penetrate the hierarchy.
> Our Synopsys rep told us that we would have to manually traverse the
> hierarchy removing these for it to work. He said that using a:
>
> remove_attribute find(design,"*",-hierarchy) dont_touch
>
> would not even work (no real explanation given).
>
> Rather than do that, we loaded the Verilog netlist of the entire design in
> and ran translate on it. This worked great since all constraints and
> attributes are not present. But, many of our buffer networks had been
> removed. Apparently, Synopsys does some optimizing in the translate step.
> Since we had no constraints, it decided that these buffers were not needed.
>
> So we loaded each sub-block .db file and ran translate on that. This does
> have constraint info. But, alas, our buffer network was still destroyed.
>
> I am now trying an incremental compile. But this is so time-consuming,
> I'm about to start over from VHDL.
>
> I totally understand that translate must use some smarts when figuring out
> how to map cells that don't exist in the new library. But a huge selection
> of buffers do exist and it sees fit to just take them out. Any ideas on
> why it does this? Or how to solve my original translation problem?
>
> - Chris Cope
> Pinpoint Solutions
From: Robert.Marshall@sinbad.nsc.com (Robert Marshall)
John,
My guess is it takes them out because "translate" is pretty much using the
same processes as "compile", and therefore the tool will try to optimise
out unnecessary cells.
I would have thought you could have don't touched the cells of the buffer
network to accomplish what you want, but I havn't tried this.
We've also been in the business of translating recently, although to have
the clock trees removed suited us fine (we actually did a proper compile
after translating).
Issues we had were:
1) Synopsys didn't really seem to understand scan flops too well -- it
replaced scan flops in library 1 with ordinary flops plus muxes in
library 2.
2) Similarily, it didn't handle latches with resets very well -- instead
of mapping a latch with reset in library 1 into a latch with reset in
library 2, it replaced the latch with reset in library 1 with a latch
without reset plus gating around the D and EN inputs to come up with
the reset function, which we decided was not a smart way to go.
You might want to check these gotchas aren't happening in your case.
- Robert Marshall
National Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Bob Wiegand <rwiegand@ensoniq.com>
John,
To remove the dont_touches, try this:
foreach (des,find(design)) {
current_design des
remove_attribute current_design dont_touch
}
current_design <top_level>
where des is just a loop variable, feel free to use whatever name you prefer.
Don't forget to change the current design back to the top level before
continuing. The same technique can be used to restore the dont_touches
after the translation.
The buffers are a different story. If you need to preserve your existing
clock buffer tree, try using wrappers to instantiate the equivalent buffers
in the new technology. Create db files for these wrappers with dont_touches
on the instanced cell but not on the wrapper itself. Instead, do a
set_ungroup on the wrapper db to eliminate the extra level of hierarchy at
the next compile, or do an ungroup on the wrappers in the designs where they
are instanced.
The ideal situation would be to have a pre-layout hierarchy where the
top level instantiates a pads block, a clocks block, and the core(s)
with their hierarchy below. This also assumes a clock tree insertion
tool in the back end. The pads block allows instantiation of the pad
cells, and the clocks block allows for instantiation of clock tree place
holder cells, as well as any clock dividing logic. The core(s) can then
be constructed with ideal clocks with the appropriate delay and
uncertainty, and no buffers (pre-layout, of course). The translation is
then performed on the core only, with much fewer headaches.
Hope this helps.
- Bob Wiegand
Ensoniq
---- ---- ---- ---- ---- ---- ----
From: "Russell Ray" <rray@msai.mea.com>
John,
I hear your woes on using the translate command. If you have a large number
of cells that are the same in the different libraries (named the same) why
not just read in the verilog with your link library and target set to the
new library?
If the cells are not named the same but you want to preserve pretty much the
same cells, then the best thing to do is write a script where you decide what
cells should be "translated".
The translate command will remove buffer trees since it sees them as
unnecessary even if it is your clock tree. It does give you your design
in the new technology, but you have to run compiles to get your timing back
and sometimes your buffer trees. If there are many things like that, it
is almost easier to start from the RTL and re-run all your scripts.
Hope some of that helps,
- Russell Ray
Mitsubishi Semiconductor Durham, NC
---- ---- ---- ---- ---- ---- ----
From: "Chris Cope" <chrisc@ppsol.com>
John,
What we had to do was a compile -only_design_rule. We set the target
library to the new library to do this. Since we had dont_touches in
the hierarchy, it did not traverse. Even doing a remove_attribute on
all dont_touches in the design didn't help. So we had to do this
procedure bottom-up.
There was another complication once we had converted all bottom level
cells. On the next level of hierarchy, there was some glue logic.
So we translated that and saved it. Then we had to remove_design on
all blocks that it contained and read in the new blocks. Then we had
to rename design in some cases so that the .db file would link
together properly. Whew! What a pain.
- Chris Cope
Pinpoint Solutions
|
|
