( ESNUG 470 Item 8 ) -------------------------------------------- [10/31/07]
Subject: ( ESNUG 456 #10 ) Palladium II needs better Green Hills support
> We have seen a 2x improvement in Palladium II's maximum speed for the
> same size models. For example, for models that ran between 150-800 kHz
> on Palladium I, we are now in the ball park of 300 kHz - 2 MHz.
>
> - Joerg Kayser
> IBM Labs Boeblingen, Germany
From: Javier Rodriguez <javier.rodriguez=user domain=analog not calm>
Hi, John,
Our ICs are used in video compression, HDTV wireless systems, and markets
that require high bandwith video. They are typically in the 1+ M gate count
range with approximately 65% logic 35% memory.
We started using the Palladium emulator 4 years ago. Despite its high cost
and complexity, we decided to go with it and have since updated to the
Palladium II.
Our designs use asynchronous clocks with clock gating capability. Palladium
provides some degree of support for multiple clocks, but it does not support
true asynchronous clocking. For our verification guys, Palladium lets us
run our production release sofware on the RTL models. We currently use
synthesizable Verilog testbenches alongside the Verilog RTL model
It took approximately 8 weeks to get our initial environment set up with the
Palladium I, including hardware models and firmware environment. It took
about 3 weeks to transition to the Palladium II (i.e. porting over our old
environment to the new one). Cadence had one field engineer assigned to our
team for both tasks.
While the Palladium I took approximately 15 minutes to synthesize & compile
our models, Palladium II now takes roughly 4 minutes to do the same. As far
as simulation speeds, Palladium I supported simulation up to 300 KHz while
the Palladium II has increased that to 600 KHz. While Cadence claims that
Palladium II supports system clock speeds greater than 1 MHz, if you need to
do clock re-sampling, that speed will really be 500 KHz or much less.
Palladium II's debug capability is thorough. Unlike FPGAs where signals of
interest have to be synthesized as ports to be able to see them, in
Palladium II, all signals can be probed and even better, triggered on (much
like a logic analyzer). This makes finding a bug at a system level much
easier than with RTL/FPGA simulations. This has had a direct impact on
reducing our design/verification cycles dramatically.
One thing worth mentioning is II's ability to interface to the Green Hills
IDE MULTI; it has a compiler, linker, and debugger. In our environment, we
set up the debugger to talk with our hardware model (Palladium) through the
GHS Target Debug Devices ("Green Hills Probe" and "SuperTrace" Probe). The
Green Hills Probe uses JTAG while the SuperTrace uses both JTAG and ETM.
We use both probes, depending on the compiled model setup.
This capability is absolutely critical in our software development & debug.
Using the standard JTAG port, the GHS software debug tools can basically
control the hardware model, read registers, set processor break points,
etc. There are some drawbacks however. We cannot use JTAG at true hardware
speeds due to the II's clocking limits. The fastest system clock for a
Palladium II system is approximately 600 KHz, so our JTAG port has to be
significantly slower.
Another feature we use heavily is II's ICE (In Circuit Emulator) mode. This
lets us synthesize both the testbench and the model and run at the highest
speed possible. It's useful when we need to process many frames of video in
a given test while still keeping checking capabilities. Regression testing
is also valuable because it allows us to verify our hardware/software models
against all our directed tests. We can use these regressions to confirm
that a change in hardware or software has not adversely affected any other
functionality in our models.
As an Accelerator, II is as close as we can get to silicon and still have
full signal visibility with all our hardware models and software code.
II's weakness for us has been that every setup or environment we use needs
to be custom tailored. There is no standard way to set up a model. Each
model or environment requires tweaks or having to do things specific for
that model. There is no common standard method for interfacing to third
party debugger tools (like Green Hills) as well. Each setup requires
interaction with a Cadence engineer to apply custom timing parameters.
Cadence definitely needs to improve Palladium's support for 3rd party debug
tools. They should do some qualification with some of these tools to verify
both systems can function correctly.
The learning curve on II is steep as well. There are things that can go
wrong at the system level, and sometimes tracking the problem to a tool
issue or a user error takes a lot of people cycles to resolve.
For teams developing SOCs requiring large amounts of data for testing and
evaluation, II is an asset well worth the cost. Just be prepared to spend
time and engineering resources to fully get it to deliver.
- Javier Rodriguez
Analog Devices Inc. Austin, TX
Index
Next->Item
|
|
