( ESNUG 435 Item 9 ) -------------------------------------------- [12/08/04]
Subject: Cooley Chastened For No Cadence Testbuilder In The DAC Survey
> WHAT DO YOU THINK ABOUT THE "C" EDA TOOLS? Forte Cynthesizer?
> CoWare ConvergenSC? Cadence NC-SystemC and TestBuilderSC? Synopsys
> CoCentric? Mentor's Seamless? Adveda Miss Univers? Y Explorations?
> Carbon DesignPlayer? Tenison VTOC? Summit Design Visual Elite?
> Target Compiler Chess/Checkers? CoWare's LisaTek? Silicon Hive?
> Synfora's Pico Express? Tensilica? Critical Blue?
>
> HOW ABOUT DSP STUFF LIKE MathWorks Matlab & Simulink vs. CoWare SPW
> vs. AccelChip vs. Elanix vs. Catalytic vs. Synplify DSP?
From: Mike Bly <mike.bly=user domain=worldwidepackets spot calm>
Hi, John,
You forgot to mention Cadence Testbuilder in your list of C tools.
TestBuilder: (as I understand it) was a side project by a group from
Cadence, to create C++ based libraries that allowed you to use C++ to
create i/f models, expect-generators, even write tests in C++, all of
which "works" with your simulator (in our case NC-Verilog).
TestBuilder is very powerful tool and well suited for large scale design
efforts. I see it as a pre-cursor, or a proving-ground, for C or C++
based behavioral modeling going forward. Whether it is eventually going
to be called SystemC or System-Verilog, or freds_neat_code, I believe
TestBuilder is a solid starting point today.
I said large scale designs above, because for down and dirty small
designs/validations, nothing beats a pure Verilog effort. Use the right
tool for the job, right!?
That said, we used TestBuilder in-house (with nc-Verilog) to prove out
a 2M gate design with 4Mb of on-chip RAM, at the chip-level. We did a
hierarchical validation of this chip, using stand-alone Verilog based
testbenches for the major modules, and as stated above, TestBuilder at
the chip-level. I do not believe we would have been able to validate
this design in the same time-frame with a Verilog-based testbench at the
chip-level. Languages such as C++ that have concepts like dynamic memory
allocation for arrays, allow your run-time images to be so much more
efficient than Verilog, which requires you to defined worst-case, largest
possible "expect arrays", etc. in your testbench up front at compile time.
There are many more aspects of TestBuilder that we found useful. Just
trying to not be too long-winded.
The TestBuilder contructs allow you to declare variables with specific
properties. One of which is "random ranges", what TestBuilder refers to
as "keep only" values. For example, let's say I want variable X in my
test to be a 4-bit register, and I want it to be able to have any random
value in the range {3..12}. In TestBuilder, you can do this in one line
when you declare the variable. This is extremely powerful, and enables
you to simplify your tests, by not having to run a while-loop, rolling
the dice with $random, until you get a value in that range. It just
makes the tests you write that much cleaner and more straight forward.
Overhead... the only overhead was at startup. The TestBuilder compilation
time for the C++ testbench was a bit lengthy the first time, but "make"
helps quite a bit after that first "build". Once the simulation started
up though, it ran at a good speed. No real metrics, but when you have used
a tool like NC-Verilog for a number of designs, you get a feel for how long
the simulation of a design of a given size should take, and with
TestBuilder on top of NC-Verilog it was right in the "expected" range for
our design size, with no "perceived" degredation in performance. In fact,
given that the testbench is more nimble with the ability to perform dynamic
memory allocations on the fly, one could argue it would have run faster
than a comparable straight Verilog testbench.
Gotcha's... the one gotcha for any language or library that suppports
dynamic memory allocation, whether is C, C++, TestBuilder, SytemC, etc, is
memory leaks. When you allow dynamic memory allocation during runtime,
having good house keeping practices is a must. Right now finding those
leaks involves some tedious black magic. This is one area I would
recommend Cadence (and the rest of the industry) put some thought. If
you don't provide the engineer with an easy way to solve this, it quickly
becomes a hinderance to using the tool.
The learning curve for someone who dabbles in writing C or C++ based
scripts here and there is steep but not too painful. There's new concepts
like methods and classes to come up to speed on. Luckily we had a C++ guru
on our team, which saved some our asic-purists, who knew only Verilog,
Awk, and Tcl. :) In fact, we brought in an instructor, and had a
week-long crash course in C++ to get our feet wet. I think the big issue
is not with TestBuilder itself so much, as "this is new". I liken it back
to the transition from schematic capture to HDL's. There are purists, and
those more open to change. There will be growing pains, but C-like
languages are going to be the future of ASIC design and validation.
In short, TestBuilder is new, it's growing, it's evolving. I can't wait
to see the end result. What is there today is a very powerful tool with
tons of flexibility.
- Mike Bly
World Wide Packets, Inc. Spokane Valley, WA
|
|
