On 15/05/14 04:40, [email protected] wrote:
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
I started to do essentially the same thing, by hooking up Tcl to GHDL.
Compile VHDL files, rough out a quick scripted testbench. Run the
script. Change the script a bit, run it again. No compilation between
running the scripts. That's about as interactive as I'd want to get. But
then the script is there ready to be expanded on for a complete
testbench. You could of course make it more interactive however, as you
described above.
As an example, see the short testbench script here (shown in the second
code box on the page):
http://pdt.github.io/script-tb_uart_tx_ex.html
The idea of scripting a testbench is nice because of the no compiling
between testbench modifications. You can make top level ports readily
available (which is what I've done here), so no need to create an
instance UUT, and no declaring signals and connecting up the UUT. And
you can build in lots of nice features, such as dynamic threads, etc.
You mention convenience with scripting languages, that's essentially
what I was aftero. Scripting testbenches means you get more flexibility
and significantly less typing vs VHDL, making it easier and quicker to
write testbenches.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
