Le 2014-05-14 08:27, [email protected] a écrit :
Hi again :-)
an idea crossed my mind, and I seem to remember that GHDL has some
cool
features under the hood, so it might be useful :-)
I'd like to automatically generate a VHDL wrapper for somewhat
arbitrary designs. I can try to parse the top level's entity
declaration
but 1) GHDL already parses so why rewrite a parser ?
and 2) the VHDL declaration might contain stuff defined in other
files.
This means that I would have to export the interface after
elaboration,
while interfacing with the program with some additional code,
but how would I do ? Is VPI a good solution or overkill ?
Can you sketch a little example ? Do you want to drive a design
from C ? In that case, VPI/VHPI would be the obvious solution
(although may not be available yet in ghdl).
Tristan.
Actually, now that I think of it, once I have the top level port
definition,
the next logical step is to drive the bits... whatever the language.
C/VPI sounds the natural choice. I can find stuff from 2010 but
1) VPI looks like a huge machinery... Don't know if I can dive into it
like I did with VHPI/foreing interfaces (way easier to play with)
2) what is the status of the support in GHDL ? Has it progressed ?
what is useable ? Can one actually list pins, read them and drive them ?
So there are two approaches :
- do something with VPI. Looks painful but powerful.
- "somehow" extract the informations from the VHDL file,
hoping that the port widths are not generic-defined and the types
are
std_logic_vector (good luck)...
My initial thought was : ok, here is another mad VHDL file that I coded
for hours and that grew without even a single test or compile. Now
I have to spend as many hours writing a toplevel testbench to drive
all the possible cases and the thought is alarming.
I didn't do the TB first because my design evolved quickly, even
on the interface, and I'd love to have a sort of tool that,
in one commande, compiles the file(s), exposes the pins and lets me
interactively
read and act on them to check basic functionalities.
Bonus points for recording my commands, make a history file of all the
commands and assertions and then export them as VHDL testbench.
I think i'm getting too used to the "convenience"
of interpreted/dynamic languages ;-)
What are your opinions, everybody ? I believe it's not THAT difficult to
write and I'm sure this tool would be used by many. It's not my first
priority right now but if nobody else does it, I'll do it anyway "one
day"...
I know the mantra "Design for Test" but we sorely miss the "Test for
design"
corollary in the VHDL world...
YG
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
