( ESNUG 212 Item 1 ) ---------------------------------------------- [3/9/95]
Subject: (ESNUG 211 #7) "Looking For Gotchas In Using Synopsys With Cores"
>My new ASIC project is contemplating using an outside vendor w/ Application
>Specific cores (like UARTs and SCSI) with Synopsys/Verilog as the design
>vehicle. Do you know of any caveats with this design combination ? Are
>there any specific questions I should be asking the vendor when using this
>approach?
From: [Mr. Foundry Man]
Hi John,
I don't want to implicate my employer (or customer, for that matter), so
please keep me anonymous! This reply is generally applicable to any vendor
that requires more than one library object to be linked in, but this
designer's request pulled my /RAS:
Our gate-array library separates gates and mega-macros (cores, memories, etc)
into separate .db library files. So the link_library usually looks something
like this:
link_library = { "*", GATES.db, MEGA.db }
We also provide wire-load models for use with auto_wire_load_selection.
However, each gate-array master requires a different set of wire-load models,
so rather than compiling the wire-load selection table into the library
object, we require the user to run "update_lib" to bring in the wire-load
selection table for their chosen master:
auto_wire_load_selection = "true"
set_wire_load -mode "enclosed"
update_lib -overwrite GATES.db WIRE_50KMASTER.lib -no_warning
Here's where the problem occurs: We had to patch the GATES library to fix
some erroneous timing values. But, rather than re-compiling the GATES
library (we had many reasons for not doing this) we instead released a
"patch" library which contained only the fixed cells. Then the link_library
was set up this way:
link_library = { "*", PATCH.db, GATES.db, MEGA.db }
Now, update_lib would report that everything was still going swimmingly.
But somehow, neither I nor the customer "noticed" that there was no
reference to wire-load in the compile logs or timing reports! In fact,
the wire load selection table for GATES.db was completely ignored!
To work around it we had the customer "update_lib" all of the libraries
in the link_library list. It may have been sufficient to update_lib
only the first library -- I never had a chance to check this out.
Anyhow, If your asic vendor uses multiple library objects, you may want to
be aware of this gotcha!. Thanks for your great information.
- [Mr. Foundry Man]
---- ---- ---- ----
From: monsen@cc4.compcore.com (Kris Monsen)
John,
Our company (which you actually visited as a consultant for one of your
customers) is in the business of selling cores using Verilog/Synopsys as
the "design vehicle". In our experience this process works just fine (of
course, I suppose we wouldn't say if it were otherwise...).
In general we ask of our customers:
1) Information about the environment in which the core will be instantiated.
For Synopsys, specifically:
- required cycle time (naturally)
- expected input drive strength of gates driving the core's inputs
- expected load capacitance on the outputs (at least differentiating
between outputs driving interconnect between blocks and a chip's pads)
2) "dont_use" lists of library cells if you have some restrictions for
testability reasons.
3) What format the netlist should be in (Verilog, EDIF, etc.).
The core supplier should provide you with information in some organized
fashion about the input setup time requirements and the output delays
(which they should at least be able to get by characterizing their design
and using write_script).
For design verification:
1) You should decide whether Synopsys as a pre-layout static timing verifier
is sufficient, or whether you want to give them a back-annotation info.
Then have them use Synopsys to improve the synthesis and/or use Verilog
simulation with SDF as a dynamic timing analyzer.
2) Find out whether they will give you a test suite and verification
environment to test their core.
In addition, the library you provide should have information about maximum
allowable transitions and/or fanouts. The earlier you exchange this
info with your supplier the faster you will converge on a usable netlist.
- Kris Monsen
CompCore Multimedia
---- ---- ---- ----
From: [Been There, Done That]
John, please don't use my name or company in this post.
In a previous job we did just this. A couple of things to consider up front:
1) Is the netlist available in Verilog? Some vendors have a methodology
where you create a black box in the Verilog design for the core, then
when you read the design into their tools substitute the core for the
black box. The drawback here is that you can't simulate at the behavioral
level to make sure your logic interacts correctly with the core.
2) Is the netlist available in Verilog *today*? In our case, once we raised
concern (1) our vendor promised to give us an encrypted netlist in Verilog
so we could simulate our design. However they were unable to produce
the encrypted netlist (once they encrypted it, neither their tools nor
ours could read it).
3) How are you going to test the core? Many of the cores we saw came with
test vectors that needed to be applied at the pins of the core. This
becomes more challenging when the core is embedded in your design, since
the core pins are not usually pins to your chip. There are, of course,
workarounds, but it is nice to be aware of this in advance.
4) Does the core compile in the vendors tools *today*? We licensed a core
that didn't compile in the vendors own tools. Naturally the core was
encrypted so it was difficult to see why it failed. Their apps engineers
discovered the core used a library cell that was obsoleted in the newer
(current) version of the library. Reconstructing the cell in the newer
version of the vendor library took some time.
5) Will the core work with other tools you might run (such as MOTIVE)?
Finally, can the vendor give you a reference of another customer who has used
the same core you are planning to use? If you're the experimental guinea
pig demand extra support and a price break for debugging their core.
- [Been There, Done That]
|
|
