Dear Alex,
first I disagree with your statement "VHDL has all the features of C".
Apart from reading and writing sequential text files the I/O features
of VHDL, at least the portable ones, are very limited.
An an example where an 'all-in-VHDL' approach isn't feasible: I have
designs which communicate with a bi-directional byte stream interface,
implemented via serial port or USB links, to a backend running on a PC.
It is very simple to write a VHPI module in C which maps that onto
a UNIX named pipe. This way I can use the very same backend software
which is used to communicate with the FPGA also against a test bench.
I found this approach highly productive, and I simply don't know how
to implement this in VHDL.
Last but not least: Often system models are for example done in SystemC
these days. One way to design test benches is to compare the response of
the synthesizable VHDL model against the SystemC model for (intelligently
chosen) random stimuli sequences. Here it is even feature that reference
and DUT='design under test' are implemented in different languages.
But my key point was: VHPI is part of VHDL 2008. Any simulator without
a good C interface via VHPI is a dead end.
With best regards, Walter
On 01/24/2012 10:47 PM, Alex Huntley wrote:
> I would disagree that integration with C is essential - far from it. I've
> never found any reason to write test-benches in C rather than VHDL. VHDL
> has all the features of C plus, has inherently a concept of parallelism
> and inherently a concept of time.
>
> The only real reason to interface with C is because a software engineer has
> implemented an algorithm in C already that you want to use. This certainly is
> a useful feature which GHDL has had for years and VHDL generally has had from
> the start through it's ability to define foreign functions. OK the VHPI
> developments in VHDL 2008 will probably facilitate software-hardware
> co-simulation,
> but as a principle I've found that VHDL is far more verstatile than C for
> writing
> testbenches. The basic problem is that people learn VHDL for synthesis and
> assume
> that is the whole language. In actual fact it is a rather small sub-set of
> the language.
>
> On 14/01/12 10:09, Walter F.J. Mueller wrote:
>> Hi,
>>
>> it is nice to think about all kinds of implementation alternatives.
>> In all this keep in mind that integration with C language programs
>> is essential for the implementation any sort of test bench. I used
>> the VHPIDIRECT mechanism in ghdl for this to interface to plain C
>> code, and this is at the very core of most of my test benches.
>>
>> I put it a little wider:
>>
>> - when ghdl wants to survive on the long run it has to implement
>> also the major vhdl-2008 language features in the future.
>> - by the time vhdl-2008 is supported by synthesis tools one wants
>> to use some of them, and it be sad if the state of ghdl would
>> prevent that.
>> - vhpi and thus "C" code interfacing is now formally part of vhdl-2008.
>>
>> vhpi and a well working C interface are indispensable functionalities
>> and any credible implementation alternative must be able to support this.
>>
>>
>> With best regards, Walter
>>
>>
>> On 01/14/2012 10:14 AM, Stephen Leake wrote:
>>> "Dr. Douglas Lyon"<[email protected]> writes:
>>>
>>>> ADA is not a real popular language (like Java is).
>>>
>>> That's spelled "Ada"; it's a name, not an acronym
>>> (http://en.wikipedia.org/wiki/Ada_programming).
>>>
>>>> The compiler should probably be ported to something like Java,
>>>> then VHDL could be a "write once, run anywhere" type language, and
>>>> that would be a hoot.
>>>
>>> It is _far_ easier to learn Ada than to rewrite a program as complex as
>>> a VHDL compiler.
>>>
>>> It is possible to target the Java Virtual Machine with an Ada compiler
>>> (http://www.adacore.com/home/products/gnatpro/multi-language/ada-java/).
>>> That would be a better way to get "compile once, run anywhere".
>>>
>>> Note that Ada is already "write once, compile anywhere, run anywhere".
>>>
>>
>>
>> _______________________________________________
>> Ghdl-discuss mailing list
>> [email protected]
>> https://mail.gna.org/listinfo/ghdl-discuss
>>
>
>
> _______________________________________________
> Ghdl-discuss mailing list
> [email protected]
> https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
