( ESNUG 440 Item 1 ) -------------------------------------------- [03/03/05]
Subject: ( ESNUG 434 #3 ) Four Users Speak Up For Mentor IKOS Emulation
> Your DVcon emulation usage share numbers are flat out wrong. You state
> that only 16% of commercial emulator users are using Mentor's emulation
> products. If we compare your numbers to market share numbers published
> by both EDAC and Dataquest, they do not line up at all. Dataquest's
> latest numbers and the EDAC 2003 numbers both show Mentor's market share
> to be over 35%, more than double what you show.
>
> - Giovanni Mancini
> Mentor Graphics Watertown, MA
From: Sandesh Bharadwaj <sandesh=user domain=mips spot gone>
Hi John,
We began using IKOS emulation back in 2000/2001, doing in-circuit emulation
(ICE) as part of our overall verification flow. In 2002, we evaluated the
VStation 15M for use in both in-circuit and simulation acceleration
applications.
Setting up the VStation for simulation acceleration is pretty much
plug-and-play. Initially, our testbench porting had to be done by hand,
but since then we have been using the Mentor TBX product, which
automatically compiles and synthesizes testbench code. Changes to the
testbench are now as easy to accommodate as are changes in the RTL; we
just recompile and restart the simulation process.
VStation has allowed us to run 1+ billion cycles of directed randoms a day.
Our designs typically have 2-3 million gates, and we regularly achieve a
clock rate of 1 MHz on the VStation. Mentor's environment also preserves
the simulation look-and feel, which made for an easier learning curve for
our designers who perform debug on the captured traces from the VStation.
We usually see about 30-40 minutes for an ICE compile, with the simulation
acceleration/TBX compile requiring 1 to 1.5 hrs.
We looked into alternatives, and Mentor was the only company that could
automatically compile and accelerate the testbench as well as compile the
design.
Being in the embedded processor business, our important verification
criteria is that of booting the Linux OS and running applications and
stress tests. We continue to use VStation in this capacity and are
continually evolving/enhancing the environment. You were looking for
data points from real users, and this is one from a happy, successful
Mentor user.
- Sandesh Bharadwaj
MIPS Technologies Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Kuo-Shuh Yan <bride_yan=user domain=xgitech spot gone>
I have used Mentor's IKOS/VStation for about two years now. When I set up
our environment, in addition to the netlist for the compiler, I needed:
- The application circuit for the I/O connection (I called it the Target
board),
- DDR memory (I called it Dram bridge because it is a target system
connected to the emulator),
- A slow down AGP bridge. To verify high end 3-D graphics, our chip
needs to communicate with the environment, which is running a normal
speed. However, the emulator runs slower than this, so we need this
bridge to communicate between the fast side of the environment with
the Design Under Test (DUT) and emulation.
- External ROM and MB. I needed one serial or parallel ROM and one MB
for GPU emulation
This was all that was needed to set the emulation environment. In fact, I
set it up without any Mentor people providing support.
Benchmark stats. Our designs vary from 4 to 30 million gates. The speed
of VStation input CLK is about 200 KHz and the actual chip is 66 MHz.
If I enable 100% visibility, it lets me see every node in the design, and
go to the lowest module possible to locate bugs. At 100% visibility, the
utilization rate is 80% of VStation's maximum capacity-also, more FPGAs
are required, which slows down the emulator speed.
VStation has a compiler switch to allow users to pack the data into fewer
FPGAs or loosen it up across more FPGAs. For some of our designs with
Mm value greater than 10.5, it's hard to finish place and route! So we
need to manage this carefully.
The biggest strength of IKOS is its size. I have moved IKOS from lab to
lab for sharing with other design teams.
Another strength are its common GUI debugging environment for people in
that let's you view signals in your design. In our debugging environment,
we can access or see all the signals, and can view them as RTL source code,
a graphical representation or as waveforms. All the different views of my
design are integrated with each other, so if you look at each in a view
and step thru time, the location on the source and graphical representation
will also change.
What we would like to see added:
- Debussy support with Verilog into VStation. VStation currently only
supports VHDL.
- Additional scripts to convert some models from assembly code to Verilog.
- We currently use external DDR memory. It would be great if Mentor
could provide an array board for SRAM to replace this.
Our company decided that emulation is necessary for our GPU chips, because
many bugs can't be found by simulation alone; for these chips, emulation
is required.
- Kuo-Shuh Yan
XGI Technologies Hsinchu City, Taiwan
---- ---- ---- ---- ---- ---- ----
From: Achim Schumacher <a.schumacher=user domain=infineon spot gone>
Hi, John,
In 1999, we made our decision to invest in VStation 5M based on its compiler
technology (virtual wires and timing resynthesis), linked with the relative
simple hardware structure based on standard components resulting in a
reasonable cost-value ratio.
We use it for pre-silicon chip verification in 3 modes:
- self contained mode (looped interfaces, testbench RAMs),
- target less mode (transaction based testbenches), and
- in-circuit mode.
Our predominant mode is currently in-circuit emulation. Here the emulator
is typically connected to the evaluation board of the later silicon. Our
test/verification environment is quite similar to our silicon lab.
We solve the slow down issues through proprietary solutions or test
equipment running with low frequencies. For example, we emulate two xDSL
transceivers connected via proprietary hardware modeling the wired line and
the analog front end, so that in the emulation environment, we can verify
the complete activation of the line between the end user and the central
office.
In the meantime, our VHDL RTL flow lets us debug with Debussy including the
back-annotated source code view. Mixed language support (Verilog/VHDL) is
available, but currently sub-optimal.
For acceptable compile times, we need a PC farm (e.g. LSF is needed due to
the time consuming place & route jobs of the embedded FPGAs.)
In recent years, the emulation frequencies of our designs range from 180 kHz
to 600 kHz, depending on the number of logic stages in the critical path.
In general we emulate in one clock domain even though the compiler supports
multiple domains. In the past, depending on the design style, constraining
for multiple clock domain compiles was tedious. Mentor claims that this is
more automated now but I have not tested it yet.
In the meantime our emulation focus has moved from pure hardware debugging,
to hardware/software co-verification and system integration due to the
higher software content of our products.
For some projects with a high FW/SW fraction, we need higher emulation freqs
than VStation can provide. For these projects we use FPGA prototyping as an
additional option. We use emulation for hardware debugging and for the first
phase of FW/SW/HW integration -- where visibility and fast turnaround times
in the case of net list changes are more important than high emulation freqs.
After the hardware design is nearly fixed, we use additional FPGA
prototyping as a pre-silicon verification/integration platform for the more
software intensive, time consuming tasks.
Although we bought our first VStation 5Ms in 1999, we still use it today.
VStation is not a perfect tool, but overall we are content with it. So we
have decided to go with the VStation 5M successor VStationPro which shows
gradual improvements in emulation frequency and compile times. It's also
fully compatible to VStation-5M IO interface as well as the complete
compile flow.
- Achim Schumacher
Infineon Technologies AG Munich, Germany
---- ---- ---- ---- ---- ---- ----
From: Shiv Kumar Gupta <shiv=user domain=broadcom spot gone>
Hi John,
We have been using the IKOS Emulators since early 2000. We currently use
VStation 15M VStation. We had initially started with a 5M gate capacity
in in-circuit mode and achieved a 300-400 KHz speed for our 2.0 M gate
design. Later, we migrated to 15M systems with a MMMCT (Broadcom's
internal version of MCT). The IKOS/Mentor support team helped us with
setting up VStation.
The major advantage with Mentor VStation is that it is a complete system
with both software and hardware. The various software pieces are
integrated nicely in a good software package which makes our work easier,
e.g. design partitioning, interconnectivity, and configurable memory chunks.
Additionally, its built-in logic analyzer with Virsim waveform viewer is
helpful for the tedious job of on-board debugging. (In 1998 -1999 period,
we used our own internally developed emulator and our debugging and
software compilation were clearly lacking.)
By using co-modeling, we get a fast bench setup. It has reduced the
dependency on external hardware equipment. The maintenance external
hardware in-circuit environment used to be major pain. Co-modeling lends
itself well for automating the verification. On the other hand, co-modeling
reduces the speed of verification in comparison of in-circuit and restricts
clocks to be synchronous.
Mentors VStation could be improved as follows:
A) Having to write special memory wrappers to map SRAMs to VStation creates
room for mistakes & wasted environment debug time.
B) The waveform dump is available for limited number of cycles. It impedes
the effective debugging in the emulator forcing go back to slower
simulations. A continuous waveform dump is a critical requirement, if
emulator is to be used for any debug.
C) The SCSI interface to the VStation's host machine is quite slow. It
takes 20-30 minutes to upload a waveform. Perhaps an Ethernet interface
would help.
D) We would prefer that VStation could allow more than one user at a time
to work on the same workstation. This is important for small cores, as
we require parallel verification, in addition to last stage emulation
in the integrated design.
E) Ability to feed asynchronous clocks to DUT is desired, as it will make
testing environment closer to the real system.
We've emulated many designs with VStation. For example, an MPEG-2 video
decoder. Emulation resolved numerous issues faster, which in the past
required a lot more SW simulation time.
Our core required a huge number of video streams to decoded: some of which
developed internally, customer provided streams, some external conformance
streams, problem stream from earlier generation of products, etc. This
can't be done with SW-based verification.
- Shiv Kumar Gupta
Broadcom India Pvt Ltd. Bangalore, India
Index
Next->Item
|
|
