( ESNUG 483 Item 10 ) ------------------------------------------- [11/19/09]
From: Takeshi Moro <moro.takeshi=user domain=starc.or.jp>
Subject: A Fujitsu engineer's detailed evaluation of the EVE ZeBu box
Hi, John,
We evaluated ZeBu back in 2006-2007 for the purpose of HW/SW co-design. We
implemented our ASIC/ASSP RTL in ZeBu to start software development in the
early design stage.
ZeBu met our evaluation criteria and we purchased it. Our criteria were:
1. Is it easy to implement ASIC SRAM with ZeBu?
Goal: ASIC embedded SRAM depends on its process library. So in the
case of an FPGA prototype, we have to make SRAMs for the FPGA. This
is a very boring task, as we must create the FPGA SRAMs manually by
using an FPGA implementation tool such as Xilinx Coregen.
Result: Zebu met this criteria. ZeBu has a utility called "zMem",
where we only need to prepare a simple script to make an FPGA SRAM.
2. Is it possible to implement a Netlist macros to ZeBu?
Goal: Our netlist is made of an ASIC library, and it was impossible
for us to implement a netlist to an FPGA directly.
Result: Zebu met our criteria. We translated our ASIC netlist to a
GTECH netlist, and the ZeBu compiler could read the GTECH netlist.
3. How can we control chip external pins?
Goal: We wanted to control our chip's external pins like reset and
mode settings. In the case of our SoC evaluation board, these pins
were connected to DIP switch or push button.
Result: ZeBu's compiler has a 'DVE' setting file with information
about external pin connections. We create the DVE file, describing
the name of external pins where we would like to control the value.
We compile ZeBu with the DVE file, and then when we run ZeBu in
emulation mode, we can open ZeBu's GUI window to control the chip's
external pin values.
4. Is it possible to connect a software debugger to ZeBu?
Goal: For example, we would like to create a software development
environment with ARM Multi-ICE software debugger.
Result: The shape of ZeBu connector and ARM Multi-ICE connector are
different. We made our own connector board to connect ZeBu and ARM
Multi-ICE, and connected the ARM Multi-ICE to ZeBu by using this
connecter board.
5. Is ZeBu fast enough for software development?
Result: Zebu met our criteria. We evaluated ZeBu performance in
MPEG4 decoding. For our 1.0-1.5 million gate design (including
logic and RAM/ROM), ZeBu could run at 10 MHz. ZeBu could decode
a QVGA MPEG4 movie at 3 frames/second. ZeBu's compile time in
our environment is about 4 hours. But this was the data in 2007.
Since then, PC specs have improved. Plus EVE recently introduced
its "Zfast" synthesis mapping of RTL to Gates for FPGAs, which
they claim will cut our earlier compile time in half, but I have
not evaluated the new compilation time using this new functionality.
Our experiences with specific ZeBu functionality:
- Automatic Compilation Flow. We didn't use ZeBu's RTL Front End, so I can
only comment on the automatic compilation flow. ZeBu's compilation flow
is very simple. For example, in most cases of FPGA prototyping, some
chip division is necessary, where one SoC is divided into multiple FPGAs.
ZeBu has strong functionality for chip division so we don't have to worry
about it. Users set a few parameters on ZeBu GUI. For example:
- Input file paths. (EDIF Netlist, DVE file, and other setting files)
- Number of FPGAs ZeBu board has
- Number of CPUs to be used for ZeBu compilation
The ZeBu compiler can divide this automatically, which is very good.
- In Circuit Emulation. We use ZeBu's in-circuit emulation so we can
develop our software in parallel with our hardware, so we'd like to run
ZeBu as fast as possible. The first time we used ZeBu, it took 6 weeks
to set up our in-circuit emulation environment. This include the time to
make our own connection board for ZeBu. The second time, it took us only
2 weeks to set up ZeBu's in-circuit-emulation environment.
- Probes. We used ZeBu's 'Dynamic probe' and 'Static probe' functionality.
Probes are used to read internal signal values during emulation. Here
are the differences:
Static Probes. We can see the waveform of the signal by using the
static probes so we us this function for bug analysis. Static probes
are created during compilation (which is a drawback since once
implemented, they cannot be changed without re-compiling the design,
which is a time-consuming process). Static probes are limited in
number (few thousands per FPGA), but do not degrade the execution
speed of the emulator. They are typically used to store signal
values into on-board RAM.
Dynamic probes. Dynamic probes are easy to use and do not require a
special setting before compilation, which makes it easy for us to
change them. You can use Dynamic probes to read sequential
(registers or memories) or combinational (gates) signals in any
quantity, but they slow down the execution speed of the emulator to
few kilohertz. The dynamic probe can display all values of a signal,
but it does so at Khz speed rather than the MHz speed we want. So
we don't use them for our bug analysis.
Flexible Probes. EVE has added a new flexible probe function, but I
haven't had the opportunity to evaluate it. EVE says that flexible
probes merge the benefits of the static and dynamic probes, because
they are created during compilation, but in vast quantities (up to
30,000 per FPGA), can be grouped based on sections of the FPGA, and
have limited impact on execution speed. The idea is that you can
compile lots of them ahead of time and then read signals on-the-fly
as needed.
- Transactors. ZeBu has many transactors. In the case of creating a SW
development environment, we need not only ZeBu, but also peripheral
parts. Transactors are a good solution for peripherals. If there is
not a transactor we want, we make our own transactor.
We implemented a multi-media SoC for cell phones with ZeBu. Our SoC has
CPU (ARM9), MPEG4, JPEG, camera I/F, 2D graphic engine, and so on.
I think ZeBu's biggest strength is that it is easy to use. An engineer can
easily implement an SoC with ZeBu, due to its good compiler and utility.
I think the pricing is EVE's weakest point. We'd like to use ZeBu for
software development, as we have many software engineers for each project.
However, we have only one ZeBu, which is a big problem.
EVE's support was good. EVE Japan's office is only a few minute's walk to
our office. So they frequently visited our office to solve our problems.
- Takeshi Moro
Fujitsu Microelectronics Ltd. Yokohama, Japan
Join
Index
Next->Item
|
|
