As whygee pointed out Text I/O is a library issue not a language issue. Your example of using an already-written piece of code was precisely where I said multi-language simulation could be useful.
However the main point is that when you compare the languages both have the concept of functions / procedures, pointers, similar types etc, plus VHDL has a whole load of other things such as time and parallelism. Fundamentally there is nothing in C that VHDL does not have. >From your example though I have done very similar things purely in VHDL, with the benefit of introducing random timing variations, because of VHDL's core concept of time. Bear in mind that for a hardware level simulation you should be looking at the timing interfaces between the chips that connect to the FPGA, edge noise and that kind of thing. This is going to be much more difficult in C. Not impossible but VHDL is much more suited to this. I'm not saying that there is never any benefit in using C or Ada or whatever language you want in conjunction with VHDL; my point is that this is for convenience and avoiding recoding, not because it is essential because of language features. On 24 January 2012 23:01, Walter F.J. Mueller <[email protected]>wrote: > 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 >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
