FFI against VHDL for test-benches

[Spur]

I'm quite new to VHDL (about 6 months), but have a lot of
experience with C (and programming in general, about 5 years).

I've written good amounts of VHDL code already - some
for synthesis, but most for test-benches. As I read the web,
books and this group, I see even more advanced test-benches
coded purely in VHDL (mine are not trivial either - they read
and write vectors to files, with Perl scripts comparing
results).

Not long ago I discovered the VHDL Foreign Function Interface
(The Modelsim's API), played
with it a little, managed to compile and run it. Now I've promised
myself to code the next test-bench in C++, using this FFI (the
API is in C but provides for a wrapping in C++ code).

My decision gets a reinforcement when I read some of the recent
posts in this group. For example, VHDL strings (using lines of
textio, and other features), VHDL pointers, etc... I can't help
thinking - in C++ it's much easier. Why not leave the VHDL purely
for the designs, as a HARDWARE Description Language, and use C++
for testbench/simulation, where it's far superior to VHDL.

So, what do people think ? Why is VHDL still used for complex
test-benches, why people invent crazy hacks to do something
C does trivially ?
Lack of knowledge of C ? Lack of a FFI ?

 

[Jonathan Bromley]

[re. writing testbench code in C/C++ ...]

[choice to use C++] gets a reinforcement when I read some of the recent
posts in this group. For example, VHDL strings (using lines of
textio, and other features), VHDL pointers, etc... I can't help
thinking - in C++ it's much easier. Why not leave the VHDL purely
for the designs, as a HARDWARE Description Language, and use C++
for testbench/simulation, where it's far superior to VHDL.

It's far superior for certain things, but sadly lacking for others.

So, what do people think ? Why is VHDL still used for complex
test-benches,

Time, parallelism, hierarchy, visualisation.

Time:
VHDL has a completely clear notion of the progress of simulation
time. In VHDL it's trivial to make signal updates and other
activity happen at specific times, and to determine the times
that things happen. It can, of course, be done in C++, but
only with the help of a significant class library. Find out
about SystemC to see how much work is involved.

Parallelism:
VHDL has a completely clear model of parallel computation,
something that C++ utterly lacks - and yes, I know full
well that in C++ you can do anything and imitate any
model of computation, and what's more you can get at
the operating system's parallelism through threads
libraries and suchlike - but this is all either
roll-your-own, or using a complicated and often idiosyncratic
class library, or using the operating system and so making
your design and testbench non-portable (in contrast, VHDL
code is generally highly portable). Furthermore, VHDL's
discrete-event model of computation is ideally suited
to typical logic design and modelling problems; other
widely-accepted models are often better at the system
level, but inconvenient and inappropriate at the hardware
and block-verification level.

Hierarchy:
VHDL easily allows you to build statically-elaborated
hierarchy. Although of course it's possible to do this
in C++, you have to be much more careful about how to
do it, since hierarchy can easily come and go during the
life of the program.

Visualisation:
All VHDL simulators come with excellent waveform viewers,
allowing an intuitive form of debug traceback that is
very hard to duplicate in C++ using any debugger I've
ever met. And as soon as you start doing anything
with parallelism, all but a very few C++ debuggers start
to look really feeble by comparison with what you find
in a typical VHDL simulator.

There's other stuff that VHDL does supremely well that
you can only imitate in C++ using hard stuff like templated
classes, but I don't want to get involved in that because
it's an argument about style rather than substance.

why people invent crazy hacks to do something
C does trivially ?

Because they want to do VHDL. In C++ you have to invent
crazy hacks to do things VHDL does trivially, but you C++
guys are so good at blinding the rest of us with jargon
that you make it look impressive and call it a class
library. Doesn't make it any easier to use, though.

Lack of knowledge of C ? Lack of a FFI ?

I think you'll find Modelsim calls it "FLI" rather
than "FFI", but yes. Both those things. And also,
the extreme clumsiness of most VHDL FLIs. And,
worst of all, the lack of a standardised FLI,
so your C/C++ investment is not portable from one
VHDL environment to another.

There's also a simulation performance hit when using
FLIs, because they poke around in the simulation in ways
that the simulator can't determine at compile-time, so
they cause various optimisations to be suppressed.

VHDL is a pretty good programming language in its own
right. It sorely lacks OOP facilities, and it doesn't
allow you to reach out into the host operating system
in any sensible way, but in most other respects it is
light-years ahead of C++ for robustness, readability,
information hiding and a stack of other things. Put in
some real investment into understanding VHDL and its
capabilities before you dismiss it out of hand - but,
on the other hand, go ahead and do whatever works for
you, even if it means fighting with the FLI.

Using C/C++ to generate and interpret streams of
testbench data is a great idea, but please don't
waste time reinventing the wheel; find out about
SystemC as soon as you can. And watch out for
exciting developments in SystemC/VHDL/Verilog
interoperation from all the major simulator vendors.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: (e-mail address removed)
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Not long ago I discovered the VHDL Foreign Function Interface
(The Modelsim's API), played
with it a little, managed to compile and run it. Now I've promised
myself to code the next test-bench in C++, using this FFI (the
API is in C but provides for a wrapping in C++ code).

Why? Unless your VHDL sim is missing something,
this is a lot of work with no obvious upside.

My decision gets a reinforcement when I read some of the recent
posts in this group. For example, VHDL strings (using lines of
textio, and other features), VHDL pointers, etc...

Access types can be used directly to handle
variable width vectors and strings in VHDL as easily
as pointers in C or references in Java.
If you understand indirection, you don't need textio.
Here's an example

http://groups.google.com/groups?q=how_many_frames

I can't help
thinking - in C++ it's much easier. Why not leave the VHDL purely
for the designs, as a HARDWARE Description Language, and use C++
for testbench/simulation, where it's far superior to VHDL.

A testbench needs multiple processes running simultaneously
in sim time. One might generate the clock and reset.
Another might generate synchronous input data, and a third might
watch output data whenever a certain strobe occurs.
It is not clear to me how to easily do this using C++.

So, what do people think ? Why is VHDL still used for complex
test-benches, why people invent crazy hacks to do something
C does trivially ?
Lack of knowledge of C ? Lack of a FFI ?

Because once yor learn to use it, VHDL works fine
and is more than adequate for 95% of FPGA functional verifications.

Abstractions like indirection take time for a beginner
to get a grip on, regardless of the language.

-- Mike Treseler

 

[Spur]

Jonathan,

Thanks for the very insightful reply. Some
comments below:

[re. writing testbench code in C/C++ ...]

[choice to use C++] gets a reinforcement when I read some of the recent
posts in this group. For example, VHDL strings (using lines of
textio, and other features), VHDL pointers, etc... I can't help
thinking - in C++ it's much easier. Why not leave the VHDL purely
for the designs, as a HARDWARE Description Language, and use C++
for testbench/simulation, where it's far superior to VHDL.

It's far superior for certain things, but sadly lacking for others.

So, what do people think ? Why is VHDL still used for complex
test-benches,

Time, parallelism, hierarchy, visualisation.

Time:
VHDL has a completely clear notion of the progress of simulation
time. In VHDL it's trivial to make signal updates and other
activity happen at specific times, and to determine the times
that things happen. It can, of course, be done in C++, but
only with the help of a significant class library. Find out
about SystemC to see how much work is involved.

Parallelism:
VHDL has a completely clear model of parallel computation,
something that C++ utterly lacks - and yes, I know full
well that in C++ you can do anything and imitate any
model of computation, and what's more you can get at
the operating system's parallelism through threads
libraries and suchlike - but this is all either
roll-your-own, or using a complicated and often idiosyncratic
class library, or using the operating system and so making
your design and testbench non-portable (in contrast, VHDL
code is generally highly portable). Furthermore, VHDL's
discrete-event model of computation is ideally suited
to typical logic design and modelling problems; other
widely-accepted models are often better at the system
level, but inconvenient and inappropriate at the hardware
and block-verification level.

Maybe I lack an understanding of some kind, but ModelSim's
API allows for this pretty easily. Lets forget the issue
of portability for the moment and assume I know for sure
I'll be verifying my designs using ModelSim's simulator on
Windows for a few years at least. I've worked through the
examples of the API, and creating processes seems very easy.
A few lines of C code, that's all. Therefore, the API also
allows for a clear notion of simulation time and parallelism.
About discrete-event model of computation -> the API "lives"
inside the simulator and just calls my code (with registered
callbacks) on discrete-events, so I don't see it as much
different from a simulator.

Hierarchy:
VHDL easily allows you to build statically-elaborated
hierarchy. Although of course it's possible to do this
in C++, you have to be much more careful about how to
do it, since hierarchy can easily come and go during the
life of the program.

I don't know enough about this (hierarchy using the C API)
yet... I may run into the problems you specify - thanks
for the warning.

Visualisation:
All VHDL simulators come with excellent waveform viewers,
allowing an intuitive form of debug traceback that is
very hard to duplicate in C++ using any debugger I've
ever met. And as soon as you start doing anything
with parallelism, all but a very few C++ debuggers start
to look really feeble by comparison with what you find
in a typical VHDL simulator.

1) IMHO, using the waveform is useful only for some cases, and
pretty simple ones. In many other cases, it's more useful to
run comprehensive test-vector sequences and assert on wanted
results.

2) It's possible to view waveforms when verifying with the API
as well, the same way as conventionally with VHDL. Waveforms
are created by ModelSIm's commands, not VHDL code.

 

[Hans]

So, what do people think ? Why is VHDL still used for complex
test-benches, why people invent crazy hacks to do something
C does trivially ?
Lack of knowledge of C ? Lack of a FFI ?

I can think of several reasons why the FLI is not used a lot. Engineers
believe the interface is complex, difficult to use, requires Microsoft
Visual C++ and slows down the simulator. First of all the interface is very
clean, well debugged easy to use and comes with excellent documentation
(each function call has a small example). If you are running under
Linux/Unix you get access to a C-Debugger which allows you to seamlessly
co-debug C and HDL code. On windows you can use Cygwin's GCC to compile your
FLI code so you don't have to purchase Visual C++. There is also a
misconception that the FLI interface slows down the simulator. The FLI goes
strait to the hart of the kernel and as long as you don't use blocking calls
in your code there should be no speed penalty. Good example of FLI usage is
the Swift interface. Unfortunately the FLI is only available on the more
expensive SE version and this is another (main?) reason why the FLI has not
gained in popularity.

No System-C for me, I will stick with the FLI interface which allows me to
use good plain old fashion C

See http://www.ht-lab.com/fli_demo/flidemo.html for some simple socket FLI
examples.

Hans.