FFI against VHDL for test-benches

Discussion in 'VHDL' started by Spur, Sep 10, 2003.

  1. Spur

    Spur Guest

    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 ?
    Spur, Sep 10, 2003
    #1
    1. Advertising

  2. "Spur" <> wrote in message
    news:...

    [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:
    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.
    Jonathan Bromley, Sep 10, 2003
    #2
    1. Advertising

  3. Spur wrote:

    > 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
    Mike Treseler, Sep 10, 2003
    #3
  4. Spur

    Spur Guest

    "Jonathan Bromley" <> wrote in message news:<bjn2fg$ghj$1$>...
    > "Spur" <> wrote in message
    > news:...
    >


    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.
    Spur, Sep 11, 2003
    #4
  5. Spur

    Hans Guest

    "Spur" <> wrote in message
    news:...
    > 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.
    Hans, Sep 15, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. yoda

    Language Work Benches in Py

    yoda, Sep 4, 2005, in forum: Python
    Replies:
    1
    Views:
    298
  2. chaitu
    Replies:
    2
    Views:
    780
  3. afd
    Replies:
    1
    Views:
    8,275
    Colin Paul Gloster
    Mar 23, 2007
  4. Skybuck Flying

    Call oddities: &Test() vs &Test vs Test

    Skybuck Flying, Oct 4, 2009, in forum: C Programming
    Replies:
    1
    Views:
    683
    Skybuck Flying
    Oct 4, 2009
  5. John Croisant
    Replies:
    0
    Views:
    96
    John Croisant
    Oct 25, 2009
Loading...

Share This Page