( ESNUG 433 Item 14 ) ------------------------------------------- [10/20/04]
Subject: ( ESNUG 431 #10 ) User Notes Palladium Has 4 Operating Modes
> It continues to amaze us as to how many design problems we can find with
> Palladium that we missed at unit level simulation. Overall, our
> experience with Palladium has been very good, although not perfect; I
> would say 9 out of 10.
>
> - Tom Paulson
> QLogic Corporation Eden Prairie, MN
From: Carl Harvey <charvey=user domain=crystal.cirrus spot calm>
Hi John,
At Cirrus Logic we use Cadence Palladium. Here are the 4 different modes
that we used during product development and our findings.
Synthesizable test bench mode: We used Palladium's Synthesizable test
bench mode. If it is true synthesizable RTL, Palladium can synthesize
the test bench. The stimulus for your chip can occur in the box itself,
which makes the simulation extremely fast. This mode is like using the
Palladium as an Accelerator. Instead getting a simulation speed of Hz,
Palladium ran it in kHz. Depending on the design size, it is actually
possible to get it to a MHz speed.
Co-Simulation mode: Initially, we used Palladium in its Co-Simulation
mode, with part of our simulation running on a workstation (e.g. NC-Sim
or with C) and part of the simulation on Palladium. But we stopped
using the co-simulation mode because the communication between the boxes
was too slow for our purposes. Co-simulation is mostly useful if the
design isn't synthesizable and you want to run it on the workbench or
you have to do S/W debug during your simulation. In general, we found
the synthesizable test bench mode was better than this mode.
Vector mode: In the Vector mode, the chip goes through a cycle as if on
a tester using real silicon. You apply the stimulus/vectors (i.e. you
"wiggle the pins") and the chip responds. You treat the code as if
you couldn't see the inside the design. This mode would be good for
verifying the chip stimulus, but we never tried Palladium's Vector mode
because it wasn't needed for our design verification.
Logic Analyzer mode: Our group preferred using Palladium in Logic
Analyzer mode. With this mode, Palladium's software allowed us to
attach real I/O devices, to capture and to read/view signals in the same
way that you might for a board with chips--except that you don't need
the board. We actually attached a mouse, an Ethernet port and a USB
mouse to the Palladium box. With Palladium, it isn't as fast as an
actual system development board, but it is fast enough for debugging
purposes. This mode was the most valuable to us because we wanted to
connect real devices to the Palladium box. For our multimedia IC, we
played and listened to audio, browsed the web, and viewed video content.
We achieved emulation speeds of 700-750 kHz with the Palladium. Because
we had a UART device whose maximum speed couldn't be resolved with a
clock ratio that worked with the clock ratios of other external devices,
our maximum speed was limited; otherwise, we could have reached up to
900 kHz. Palladium helped us to uncover a number of problems--mostly in
video design blocks, where we could see bugs on the pixel level. Using
other methods like traditional simulation or acceleration boxes, it
would have taken days to weeks before getting a dump file that would
have been too large to view. With Palladium, we ran simulations quickly,
found bugs quickly and fixed problems quickly.
It's worth noting that to do audio/video, we needed a speed bridge to
step down the frequency to a ratio that the Palladium could handle.
Someone had to design the speed bridges, but they can be reused
depending on the IP.
Methodology: The nature of our IC products call for both verifying with
Palladium and building an FPGA prototype. First we do simulation, then
we emulate with Palladium, then we implement the chip as an FPGA.
Palladium is a cycle-based emulator, so it has no timing. In contrast,
the FPGAs do have some inherent gate delay providing some timing
simulations and the FPGA system runs faster. We do higher level testing
with the FPGA system. But with an FPGA system, the board must be designed,
fabricated, and the RTL design must be properly partitioned. We run
simulations on the Palladium while the FPGA system goes through its
design cycle. Eventually, we use the Palladium and the FPGA platform in
parallel.
Some Palladium limitations: We have an asynchronous system with multi-clock
chips. Palladium can't find synchronization problems, so now we must
supplement the Palladium with another tool.
We would like Palladium to support SystemC and PSL on the box. Cadence
may already support property specification language (PSL) for assertions
but we haven't tried it.
Capacity: One Palladium "domain", meaning a group of processors will
give you about 1 million gates. You can buy as many domains you want. A
board is populated with up to 4 domains, 4 million gates, and we used a
2 board box. Our project using Synopsys' dc_shell was 500 K gates; but
with Palladium, it was 750 K gates. It didn't synthesize as well, and
the standard cell library was different -- which introduced a small amount
of risk.
- Carl Harvey, Jr.
Cirrus Logic Austin, TX
|
