( ESNUG 450 Item 10 ) -------------------------------------------- [01/25/06]
Subject: ( ESNUG 443 #1 ) Two customers detailed reviews of Mentor Vstation
> However, the VStation is fast. We measured the time taken for the SW to
> be downloaded into DDR memory, fetched and processed by the internal
> processor. The result showed that the VStation was nearly 3 times faster
> than the Palladium. The way the two emulators handle clocking is vastly
> different and worth a mention here. The VStation allows for the use of
> 14 external asynchronous clocks, which can be routed directly to each FPGA
> within the emulator. This gives the system the ability to emulate true
> asynchronous clock domains. The Palladium prefers to have its clocks
> internally generated. All external input clocks are sampled by an
> internal system clock, which results in synchronous clock domains.
>
> - Fiona Chua
> Philips Semiconductors Southampton, UK
From: Hong-Lee Koo <hong-lee.koo=usr domain=infineon hot mom>
Hi, John,
I first started using Mentor's VStation in 2002, in San Jose, though
Infineon has a much longer history in Munich, Germany. My main evaluation
criteria was speed/performance and user friendliness.
There are 3 primary methods we considered, with the following trade-offs:
1) In Circuit Emulation -- with memory inside the emulator
Pros: Just emulator needed; Low development effort
Cons: Testcase size limited by memory; Memory up-/download slow
2) Co-modeling (targetless)
Pros: Unlimited testcase size; fast/more flexible
Cons: High development effort; BFM/MCT needs; emulator resources
3) Targetboard -- with memory outside the emulator.
Pros: Most realistic test-scenario; fastest, no resources for TB needed
Cons: Target board needed; target board must be able to slow down
We have experience in setting up two kinds of emulation environments: the
MCT-targetless approach (co-modeling), and the targetboard approach, with
physical boards connected directly to the emulation.
I used IKOS in 3 projects over the past 2-3 years.
A. IP phone
- Mixture of VHDL and Verilog. Estimated gate count: ~1 Million.
- Target => IXIA Ethernet packet generator
When we first were setting up the environment, the VHDL compile flow
was still in a preliminary phase. We requested that a Mentor consultant
work with us throughout the entire project.
B. ADSL
- Pure VHDL. Estimated gate count : ~2.5 Million
- Targetless. MCT based.
We had a utopia transactor, host transactor and so on... to do the
translation from the C model/testbench to the DUT inside the emulator.
C. ETHERNET-ADSL
- Mixture of VHDL and Verilog. Estimated gate count : 1.3 Million.
- Target board with serial/parallel Flash, EJTAG, SEEPROM, UART
Mentor's VirtuaLogic has a long history and is quite mature. Its strongest
points are (with only some effort) we can to map the whole design into the
FPGA, and it allows us full visibility for easy debugging the design. This
is very, very useful.
VStation is fast, but not compared to an FPGA prototype -- most of our test
cases are limited by speed. The frequency I obtained in the 3 projects was
only about 200-300 kHz, which was 1000x slower than the real system. We can
gain higher frequencies from FPGA prototypes -- around 10-40 MHz. This is
about 100x faster compare with IKOS Vstation. Of course, with FPGA proto-
types, the development effort is higher and it is harder to debug.
We have certain coding styles we use that IKOS VStation can't interpret. We
normally report this to Mentor, and they send a patch file. One workaround
we do is to replace the faulty module with a Synopsys synthesis netlist. We
also had a bad experience with logic misbehaviour inside the FPGA. This
happened in my first project, IP phone -- the OR of the two "0" inputs
resulted in "1" instead of a "0"! The fix was delivered after our tapeout.
We also had problems with the long path/combinational cycle for latch-based
design (for example OAK.) So we first do emulation, then do FPGA prototype
as a last step.
We run an MCT simuation to set up our environment before we actually compile
and run the emulator.
System Emulation MCT RTL Gatelevel
Sim Sim Sim
MasterClock 566 MHz 250 kHz 100 Hz 33 Hz 8 Hz
Bit Proc Clk 283 MHz 125 kHz 50 Hz 16 Hz 4 Hz
Sig.Proc Clk 94 Mhz 42 kHz 16 Hz 5 Hz 1 Hz
DSP Clk 160 MHz 71 kHz 28 Hz 10 Hz 3 Hz
Frame length 230 us 500 ms 20 min 1 hr 4 hr
Mentor's support for VStation is rather satisfactory. However, when we do
encounter problems, we can't expose our RTL/netlist to Mentor, especially
the RTL that is under NDA. So sometimes this means we can't proceed while
Mentor can't solve the problem. This will create a deadlock to some extent.
In a normal situation, we will try to scale down the entire netlist to just
the part that is giving us problems. However, sometimes this is a waste of
time as the problem might only occur when we have the entire netlist, and
will not appear if we only have the 'problem' netlist.
We have successfully connected the Ethernet-MII, Ethernet-RMII, EJTAG,
Serial flash, SEEPROM, UART to VStation. They are all running in slowdown
mode. Our practice here is to try to have a single clock domain, all other
clocks are derived from this system clock. This might affect the performance
somewhat, but it helps reduce the complexity of multiple asynchronous clock
domains.
I would recommend Vstation IKOS. It is expensive but yet worth the money.
These days, we not only use emulation for design verification, but for SW
development. We tapeout our chip only after certain level of SW development
is done. This allows us to gain higher level of confidence before the
chip is out.
- Hong-Lee Koo
Infineon Singapore
---- ---- ---- ---- ---- ---- ----
From: Wei Chi Chen <wcchen=usr domain=admtek.com.tw>
Hi, John,
The main issue in our network designs is that we need to see the rate per
second in the smart bit.
Our debugging environment uses VStation software on a Sun workstation. The
VStation emulation system is interfaced with the Smartbit analyzer via an
interface cable. The target boards, e.g. CLK Generator, Reset Generator and
Default setting, are also interfaced directly to VStation.
Our product is a five-port Ethernet switch. Our chip has embedded memory.
In our original design, we had 12 clock sources, but to reduce emulation
problems, we decrease the clock sources to only one.
I think the capacity in VStation is sufficient for our designs. But when the
Ethernet speed is 10M, we can't see the correct behavior (too slow).
Though their documentation tells us not to run IKOS at a speed greater than
32 MHz, we actually run it an emulation speed at 40 MHz. This way the system
clock (originally 50 MHz) can run smoothly at 563 Khz (no duty cycle) and
615 Khz (duty cycle 55%, 45%).
Here are the IKOS switches we use:
-Mm is a switch used at a global level. We use it at the beginning. It
controls amount of logic in the chip-it lets us pack more or less in.
First, we pack a lot in, then we run a compile once. The majority of
design have no problems, but some have a tougher time fitting.
-Mmfanout controls the setting for routing congestion. Mmfanout helps
whenever FPGA compiles take longer or don't pass place and route.
-CUi. We do Mm globally, and then we use the CUi switch to help the
individual FPGAs compile. We partition our design into different
FPGA's. CUi is a switch to manage the capacity utilization on a
specific FPGA or part of the design to give it more resources.
In our design, we find that these switches (-Mm, -Mmfanout, -Cui) can
affect the emulation speed to some degree. On the other hand, running
Vstation for 100% visibility -- Mentor's default setting for viewing all
the design nodes -- doesn't seem to affect emulation speed.
- Wei Chi Chen
ADMtek, Inc. Hsin-chu, Taiwan
Index
Next->Item
|
|
