Editor's Note: On the road again! Seems like SNUG and OVI were just yesterday
and I'm off to California for another week of conferences. [I was once asked:
"John, what do your sheep do when you're away for a week?" Before I could
answer, a friend quickly retorted: "They sleep with both eyes closed!"] :^)
Anyway, this time it's VUIF plus the very first meeting of the EII '94, which
stands for the EDA Integration and Interoperability conference that's
being sponsored by the CAD Framework Intiative (CFI) people. (I'm actually
very interested in what's going on at EII '94 because I've had to deal with
more than my share of interoperability issues as a Project-In-Crisis
consultant.) And although it's partially overlapping with the last day of
VUIF, I'm told that it's NOT intended as a "VHDL Uber Alles" spillover
meeting. (EII '94 is targeting all EDA users -- sorta like a mini-DAC with
an emphasis on getting various EDA tools to play nice with each other. They
just timed with VUIF to get more users than a first time stand alone
conference could get on its own.) It's next week on May 4-5 at the Claremont
Resort and Spa in Oakland. (To register, call (512) 338-3739 or e-mail
"gallagher@cfi.org" or just do a walk in registration!) Hope to see ya there!
- John Cooley
the ESNUG guy
( ESNUG 187 Item 1 ) ---------------------------------------------- [4/94]
Subject: (ESNUG 185 #5) "Seeking Quickturn Emulation Horror/Success Stories"
>I am responsible for the emulation phase of a large scale design featuring
>several LSI 300K ASICS. Due to the complexity, the quantity of ASIC slices on
>the board (up to 26 instances), and the risks of having to respin chip after
>chip, we have chosen to emulate our designs using QUICKTURN Design's MARS
>system. My question, does anyone out there validate their designs using
>Quickturn, or any alternate emulation techniques and if so, have you found
>any specific problems in ICE (In-Circuit Emulation) that might affect how we
>generate our Synopsys output?
---- ---- ---- ----
From: don@westford.ccur.com (Don Monroe)
OK John, here's the "unmarketized" write-up of our Quick-turn experiences
you've been pestering me for (and as I promised to do):
History (April 1992)
We evaluated both Quick-Turn (RPM+) and Pie (MARS II) and chose Pie for
their higher density of small (2K bits) RAM blocks. Since then the two
companies have merged and are only selling MARS III. We were the first
east coast account for Pie Design Systems so we made a business deal with
them to be a reference account. (In December of 1992 we were one of the
first sites to receive the MARS III software and the LBM-3's.)
Configuration
We are emulating 6 devices. Four of them are 53K gates each, one is 63K
gates and the 6th is 35K gates. We built a unique version of the target
system specifically designed for emulation. It was a larger module and we
put 60-pin connectors on the back side for the cables that connected the
target to the emulation hardware. We alternated ground with the signals
in each cable so each device required 6-8 cables. (The module also
contained PGA sockets that could be used for the devices after thay had
gone to silicon. To date we have never used these sockets.)
Device Design Methodology
All the devices were designed with Verilog/Synopsys and the LSI 100K/200K
Library. The MARS software requires that you identify the qualification
of any FF/latch clocks. This requires that these qualifying signals have
user defined net names rather than Synopsys net names otherwise, you have
to keep changing the names that you tell the emulation software every time
you go through Synopsys.
Another thing we found is that the emulation system causes bidirectional
device signals to be represented by three wires in the emulation I/O
cables. Each I/O cable only contains 48 (64 in MARS III) signal wires so
you can quickly increase the number of I/O cables required. If your
bidirectionals have common enables, the MARS software is smart enough to
condence them to two signals and one control for large groups of I/O
unless you have tree'd the enable for loading purposes.
The parametric NAND tree in LSI's technology can also be a problem.
The emulation software will try to emulate the tree (causing an additional
two I/O pins per device I/O) unless you disconnect the output of the tree
or the entire tree. Since we were working with MARS II software, we
pre-processed the net list to remove the entire tree.
Some cell types in an LSI PLL design are not supported in the emulation
library ("PDTNOR", "VCO50D", "PROCMON", etc.) so our Synopsys build
process generated two different net lists. One for emulation and one for
simulation. We didn't find this to be a problem although I can imagine
some methodologies that may frown on having two different netlists.
System Design Methodology (Clock Rate)
Our system is a distributed memory multi-processor R4400. The memory is
standard DRAM requiring refresh. Each ASIC device and the processor
contained a phase-lock-loop (PLL). Since the emulation clock rate is
anywhere between 1 and 8 MHz (we were able to run at about 1.5 MHz) we
added logic to the memory controller to make the refresh rate programmable.
Each of the ASIC's and the processor was configured to run with the
phase locks disabled.
We had to add one-shots to the VME async signals because the ASIC
has internal synchronizers and the VME signals could have pulse widths
less than the emulation clock period.
We use the Intel Ethernet chip with its own dedicated SRAM memory system
(not the processors DRAM). Originally this sub-system was synchronous
with the system clock but when we decided to emulate, the sub-system was
redesigned to be asynchronous so that the etherent chip could run at the
full 25 MHz when the rest of the system was being emulated at 1.5 MHz.
We used the NCR SCSI chip (53C710) which runs just fine at 1.5 MHz.
Two of the devices we emulated contained asynchronous signals. One device
was a memory controller with asynch RAS and CAS and some latch enables.
Another device was a VME bus interface that contained a few asynch
signals. We found that we had to filter (RC) every one of these signals
on the target because of noise in the emulation cable system.
Debug
The MARS system comes with a 768+ channel logic analyzer. One problem
they have is that each analyzer cable contains 48 channels but the
emulation cable can only have 24 bidirectional signals so you lose 24
analyzer channels for each analyzer cable connected to a bidirectional
emulation cable.
We found that probing internal device nets is very easy once you've
figured out what nets you want to probe. Since the netlist was
generated by Synopsys we found that alot of the time we had to backtrace
through the netlist and sketch schematics to find the net names (the
Synopsys Nxyz name) that we wanted to probe. The MARS III software
comes with a Hierarchal Netlist Navigator to help but you will still
find yourself sketching schematics.
Even though probing internal nets is relatively easy it is not totally
painless. At a minimum it requires a partial recompile and could cause
a total recompile. A recompile could take anywhere from 15 minutes to
18 hours depending on how burried the nets are that your trying to probe.
For this reason I would definately say that emulation is NOT a substitute
for simulation. You should feel very confident that you haven't got any
bugs in the design BEFORE you try and emulate. You don't want to be
finding data-path conectivity problems with emulation. Emulation should
be used for those tricky state machines where interaction conditions are
hard to simulate.
Results
It initially took us about 6-8 weeks to partition the netlist into the
emulation hardware but this was with MARS II hardware and software. When
we got the MARS III release, the same task took about two days. Once we
started emulation, it took about 16 hours to get the R4400 processor
executing EPROM code and running diagnostics.
In the first month of emulation we were booting diagnostics from disk.
Within the first 2 to 3 months we had found approximately 4 show-stopper
bugs in the devices we were emulating. These bugs were of the type that
it would have been multiple re-spins to find them in silicon.
We fabricated parts after about 5 months of emulation. These parts were
of good enough quality to build our internal proto-types and continue
debug of the system software. One of the three device types had to be
respun for production release and another device has several external
workarounds but won't require a respin.
Our original goal with emulation was to start debug of the Operating
System earily than if we had to wait for silicon. As it turned out,
we used the emulator to debug the ASIC's and the O.S. hardly used
it at all.
I believe that I can speak for the entire design team in saying that this
project could never have been done on schedule without emulation. Just as
two or three years ago we committed to full system simulation I belive we
will be committed to emulation on any project that has significant ASIC
content.
- Don Monroe
Concurrent Computer Corp.
( ESNUG 187 Item 2 ) ---------------------------------------------- [4/94]
From: frazer@idtinc.COM (Andrew Frazer)
Subject: Synopsys Doesn't Use FLEXLM Like Everyone Else!
John,
We just learned that Synopsys does not support the "auto_timeout" and
"queueing" features of the FLEXLM license manager. Auto_timeout is very
important. For example, if a user runs the "compile" command, he
automatically checks out a license token for the Design_Compiler and no
other users can use the same token. If you only own one license, then
nobody else can use Design_Compiler.
Now, when the first user's compile job is finished, you would expect the
"Design_Compiler" token to be returned to the token pool for other users.
Not so, at least not in Synopsys. The reason is FLEXLM does not automatically
check licenses back in. Instead, the auto_timeout system goes around the
network every 15 or 30 seconds and takes back any unused tokens. This is
what Cadence, Viewlogic and Logic Modeling do. Synopsys' implementation
of FLEXLM does not support auto_timeout -- the user must manually
giveup the token when he is done with it. Synopsys tells us they chose to
do this for security reasons. It seems to me they just want to sell more
licenses.
There are some obvious problems with this implementation. For example,
a user may just get greedy and refuse to give up a token even though he
will not need it for another six hours. Also, if a user starts a job, locks
his screen and goes off for lunch, then once his job is done no one else
will be able to use his token.
Does anyone have any workarounds? Does anyone agree with me? Synopsys told
us they took this feature out because many customers requested it. If I
were Synopsys, I would have made it optional and under the control of the
system administrator.
- Andy Frazer
Integrated Device Technology
( ESNUG 187 Item 3 ) ---------------------------------------------- [4/94]
From: jackiep@SynOptics.COM (Jackie Patterson)
Subject: Painful Experience w/ v3.1a & "update_script"
Hi John-
Beware the update_script command in v3.1a of Design Compiler! (update_script
is a command to bring dc shell scripts up to date with command changes in the
new release.)
1) It doesn't work at all in design_analyzer -- use dc_shell instead.
2) The man page says its okay to use the same file as both input and
output, as in: "update_script stuff.scr -output stuff.scr" DON'T
DO IT! It will erase the contents of the file!
I've learned a lot by reading the experiences of other Synopsys users in
ESNUG. I hope this warning will save someone else the grief I went through
in discovering this.
- Jackie Patterson
SynOptics
( ESNUG 187 Item 4 ) ---------------------------------------------- [4/94]
From: mills@hwcae.az.honeywell.com (Don Mills)
Subject: Seeking Code Reuse Experiences
My group is being tasked this year as our R&D project to incorporate code
reuse into our ASIC design process. Is this feasible? Are there tools or
programs that can assist with code reuse? Can code reuse truly improve
schedules? Can code really be reused? What are the drawbacks to code reuse?
Does anyone have any experiences (war stories) regarding code reuse?
- Don Mills
Honeywell
( ESNUG 187 Item 5 ) ---------------------------------------------- [4/94]
From: rickw@fmiapd.com (Rick Weiss)
Subject: Buses With "report_timing" Are A Nuisance
John, I have a question for the ESNUG community:
I've compiled my design, and I want to find out what the 20 worst timing paths
are. So I do a 'report_timing -max_paths 20'. I look at the report, and see
that all 20 paths start at one single-bit register and end in different bits
of a 32 bit bus entering a register.
To me, all bits of that bus are the same path, and once I know that one bit is
too slow, I don't care to be told that the rest are also too slow, but instead
want to know the next slowest path.
The only way I've found is to: 'report_timing' then 'set_false_path' on its
endpoints, and 'report_timing' again.... This takes a long time, and, being
menial labor, should be done by the computer itself. Any suggestions?
- Rick Weiss
Ford Microelectronics
|
|
