( ESNUG 476 Item 5 ) -------------------------------------------- [10/29/08]
Subject: ( ESNUG 472 #8 ) We use an EVE ZeBu-XXL 8 along with Bluespec BSV
> We have an 8 FPGA ZeBu-XXL configuration, so we targeted that capacity
> when defining the sub-systems. We were able to have a CPU running at
> more than 10 MHz on ZeBu for our 5-6 Million gate designs.
>
> - Helena Krupnova
> ST Microelectronics Grenoble, France
From: [ The Little Engine That Could ]
Hi, John,
Keep me and my company out of this, OK?
We evaluated EVE's ZeBu-XXL emulator for our transaction level co-emulation
design flow in 2007. Our key evaluation criteria was to create a push-
button flow from the design RTL input files to ZeBu design database files.
We started using ZeBu concurrently during the eval phase by incrementally
increasing our chip coverage. In early 2008, we purchased a ZeBu-XXL 8,
which had a 12 million gate capacity for our wireless modem chips.
Transaction-based co-emulation:
The sweet spot of the ZeBu box is to use it for transaction-based
co-emulation using C/C++/SystemC testbenches. This is where we observed the
most acceleration -- from 300x to 1000x over pure simulation. This tends to
be a soft metric which is completely dependent on the activity between the C
testbench and the DUT.
Additionally, by using transactors to model part of the design in a C
testbench, we were able to use their box most effectively by matching the
box capacity with the design size. This is a key benefit to using this
methodology.
Given our approach, we designed all the bus level transactors ourselves.
Our transactors are synthesizable bus functional models (BFMs) and have a
matching software proxy that runs in C testbench. We define the data
packets going back and forth, and EVE provides the entire communication
infrastructure between the C testbench transactions and the transactor
implementation in their box.
We use C++/SystemC as the transaction level testbenches for tasks ranging
from bus performance modeling to system validation. We run these C
testbenches on 64-bit Linux boxes. EVE doesn't support windows environment.
The hardware part of the transactor is written in Bluespec's BSV language
and is synthesized in the EVE box with the DUT (coded in VHDL/Verilog).
EVE's C-API calls are used to communicate between these 2 parts of the
transactors. We used their faster version of SCEMI macros called ZCEI.
There is a 3-6 month learning curve the first time you implement a
transaction level co-emulation methodology and integrate with the RTL design
flow. Typically, engineers with background in hardware and software will
find it easy to adopt the transactor methodology.
Once you pick up all the tribal knowledge of how to use the box for
transaction co-emulation, it is very easy to turn the crank for ZeBu for the
next testbench or the next chip. We were able to bring up 10-12 testbenches
in about 3-4 weeks per testbench.
Other ZeBu Modes:
We also used ZeBu's In-Circuit Emulation mode, mainly to interface with the
Lauterbach emulation pod. Additionally, we used EVE's HDL cosim mode, but
the acceleration factors were low (3x to 5x) for the types of designs we
tried -- the testbench consisting of HDL simulator and HVL testbench took up
most of the time. Synopsys VCS was faster than Mentor Questa simulator by
~7x, but Questa had better support for mixed-language simulation and we
found it to be always stable.
Other ZeBu Functionality:
We completely rely on EVE's RTL front-end tool. It allows us to use
less resources plus provides an integrated flow by just inputting a list
of design files. It took some time for their RTL front end to handle all
the VHDL/RTL/Memory constructs used in our design but their support provided
patches and scripts to resolve all the issues.
We brought up all our testbenches in zTide (ZeBu Transaction Interface
Development Environment) which allowed us to simulate transactors with the
DUT in any EDA simulator using the same C-API. This let us use the same
C-testbench for zTide simulation and ZeBu-emulation. Having debugged the
transaction flow in zTide always resulted in higher probability of working
on the ZeBu hardware platform. Any remaining testbench issues were resolved
by dumping dynamic probes. It was important to remove all X's in the design
which sometimes passed in zTide simulation but failed on ZeBu for known
reasons.
What EVE Does Best:
1. Scalability. EVE's ZeBu XXL box has a modular architecture so every
8 FPGA cards have a 12 million gate capacity, or 1.5 million gates per
FPGA. A big enough box can support up to 96 million gates.
2. High speed performance. Our 12M gate designs typically ran from 1 MHz
to 10 MHz range. The speed varied depending on the design we were
synthesizing, e.g. some testbenches ran at 10 MHz and some at 1 MHz
(certain memory interfaces such as Zebu's zDDR ran slower).
3. EVE provides a complete design flow, their RTL front end takes our RTL
design files to the ZeBu box and does all the auto-partitioning.
They also have integrated synthesis e.g. Synplicity/Xilinx, so we don't
have to deal with how to move stuff to their box. It allowed us to
start integration very early in the design cycle with fewer people.
4. ZeBu XXL has lots of memory interfaces so we don't have to design your
own cards. For example, EVE has a Smart ICE interface connector
provided on the ZeBu XXL-8. We could use the pins to interface
whatever we chose. For example, we designed a cable to interface the
Lauterbach pod, so we could debug ARM code in the co-emulation environ.
What EVE Needs To Fix:
1. Although EVE supports both Verilog and VHDL, we initially faced some
issues for EVE's RTL front-end that were primarily related to the types
of VHDL constructs they supported (e.g. library name aliasing).
2. We would rediscover bugs in new releases that were already fixed in a
prior release. Although EVE has responsive email and online support
and corrected the new bugs fairly quickly, this was frustrating at
times.
3. Their documentation could be lot better with more examples on how
different modes operate.
ZeBu helped us find several bugs in our design. It also let us provide
timely feedback to architecture group as all our architectural modeling and
some validation was done using EVE. EVE has created a complete eco-system
of developing transactors and mapping them to their box, making it as push-
button as it can get.
- [ The Little Engine That Could ]
Index
Next->Item
|
|
