I got a good laugh reading in EE Times how Cadence suckered Unisys into
paying $75 million over 5 years to Cadence to take over Unisys's internal
CAD department with 150 of their design engineers. Why? Because once the
deal was inked, the VP at Unisys who helped make this decision, Richard Joy,
immediately jumped ship to become a bigwig at Cadence! (When Joy returned
my phone call, I couldn't get answers to questions concerning the reasoning
used to make this outsourcing decision. All I got was that he was Cadence's
newest employee of three days, a "I think this is the business model of the
future" and that he suddenly had another call.)
Doing a little research at my local library I found three interesting facts:
1.) Demand for Unisys's chief product, mainframe computers for government
contracts, has been shrinking like crazy since the Cold War ended;
2.) Unisys got nailed by Uncle Sam in '88 for bribing two Congressmen plus
some procurement officials *and* for overcharging on a few contracts;
3.) Unisys axed 4,000 out of 42,900 employees last year.
Given a possibly shakey future, if I was the new golden boy in Cadence who
helped make this $75 million deal happen for them, I, too, would be wildy
ecstatic in the press about Cadence Consulting!
- John Cooley
the ESNUG guy
( 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]
( ESNUG 212 Item 2 ) ---------------------------------------------- [3/9/95]
Subject: (ESNUG 211 #3) "VSS VHDL Compiled Engine Problems on IBM RS6000's"
>Are there other VSS users out there that have compiled engine problems on an
>RS6000? By problem I mean "vhdldbx" or "vhdlsim" takes an especially long
>time during elaboration, then it crashes with a message like this:
>
> dump: ...../WORK/rs6000/libCsa023840.so.1.0:
> dump: 0654-106 Cannot open the specified file.
> **Internal Error: vhdlsim: Please report (Can not link shared object file).
>
>Smaller pieces of our design will work OK compiled, but larger ones do not.
From: fyang@vnet.ibm.com (Fred Yang)
Hi, John,
Try the following and see if it works for large designs:
$cd $SYNOPSYS/rs6000/sim/bin
$/usr/bin/echo '\0200\0\0\0' | dd of=vhdlsim bs=4 count=1 seek=19 conv=notrunc
NOTE: the "dd" command is going to modify the executable code "vhdlsim".
So you absolutely want to create a backup copy before "dd".
- Fred Yang
IBM San Jose
( ESNUG 212 Item 3 ) ---------------------------------------------- [3/9/95]
From: jand@easics.be (Jan Decaluwe)
Subject: Test Compiler 3.2a Is Fantastic Compared To Test Compiler 3.0a!
John:
We have used Test Compiler for several years now, and as for many others this
has often been a frustrating experience. However, TC 3.2a has been a pleasant
surprise. Here are some important improvements:
Test insertion
----------------
Our designs typically have multiple clocks; 1 or 2 clocks drive the bulk of
the flip-flops while the other clocks are lightly loaded. Our goals with
test insertion are the following:
* flip-flops from different clocks should be in separate scan chains
* all available chains should be used and balanced as much as possible
TC 3.0c balances chains by default, but flip-flips from different clock
systems are mixed. There is a variable you can set to prevent this, but
in that case TC 3.0c refuses to use all available chains and to balance
within clock systems. You end up with only one (possibly very large)
chain per clock. The workaround involves "manual" chain allocation &
balancing and a lot of overhead work & scripts.
In TC 3.2a, test insertion works as desired (see above) by default !
Clock capture groups
----------------------
Support for clock capture groups is a new feature in TC 3.2a. This concept
prevents timing problems associated with paths between different clock
systems during the evaluation cycle: only one capture group (consisting of
a set of clocks) is active per evaluation cycle. The assignment of clocks
to capture groups is done intelligently by the tool, by taking into account
the relative position of clock edges in the test cycle, and the existing
communication paths (which can be influenced by set_test_isolate commands).
Benchmarking ATPG run time
----------------------------
We have seen a major improvement in ATPG run time with TC 3.2a, especially
on the final runs at the top level. The following table shows ATPG run
times for the final vectors of 4 recent projects.
Design Total # faults ATPG run time TC version Workstation/memory
(non-collapsed) (CPU)
---------------------------------------------------------------------
1 44336 7705.21 sec 3.0c Sparc10 128MB
2 136450 89257.55 sec 3.0c Sparc10 128MB
3 89620 700.57 sec 3.2a Sparc5 128MB
4 229598 5614.07 sec 3.2a Sparc5 128MB
All designs had multiple clock systems, RAMs, & some hard-to-test circuitry,
and achieve a fault coverage in the range of 93-96% for the core logic. I'd
recommend jumping to TC 3.2a if you're not there now.
- Jan Decaluwe
Easics, Belgium
( ESNUG 212 Item 4 ) ---------------------------------------------- [3/9/95]
From: brad@crosscheck.com (Brad Plata)
Subject: Seeking Tools/Scripts To Translate A VSS Library -> Verilog Library
Hi John,
Thanks for doing ESNUG -- it's very useful in keeping me up to date. Thanks.
Since you are the expert in this area, I need some help to convert a VSS
library from Synopsys to a Verilog liberary so we can do some testing for
IDDQ. Is there a tool that can read the VSS library and output the Verilog
models with timing (or without timing I can later add that by hand if I
have to.) I really don't want to do 400 cells by hand. If you can help
that would be great.
- Bradley Plata
CrossCheck Technology
( ESNUG 212 Networking Section) ---------------------------------- [3/9/95]
Christchurch, New Zealand - ASIC/DSP eng. for two-way radio design w/ VHDL
& Synopsys. Must relo to NZ. No Agencies. "burgessr@teleng1.tait.co.nz"
|
|
