On 16/05/14 09:26, [email protected] wrote:
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.
Now the question is how you interface/hookup.
I don't see the underlying source code of your system,
it makes me very curious :-)
Hi YG,
With regards to the interface my knowledge is actually the same as
yours. Currently I'm parsing the VHDL file for a UUT to get its ports,
and from that automatically generating a VHDL wrapper that calls my
library using VHPI. Once the wrapper has been compiled, it won't be
compiled again unless the UUT VHDL changes. So if only the testbench Tcl
script changes, no more compilation takes place.
I'm writing my own build tool to do all the background stuff for me, so
that it's _real_ easy to handle. The build tool is at
http://pdt.github.io/ttask.
In particular, the build tool allows me to easily specify my rtl code,
my simulation files, the target simulator, and whether I want
simulations to run in parallel (to make use of multicore machines), and
then it's up to the build tool to do its job. For example, here's a
complete ttask build script:
config simulator ghdl
config index ""
task test {sim build -exe noGui -index $index}
task sim {sim build -exe gui -index $index}
task clean {rmdir build}
project add sim -type $simulator
sim src -add {rtl/*.vhdl sim/*.vhdl sim/*.tcl}
sim build -buildDir build -threads 8 -dep auto
The 'sim src' line specifies where the sources are, RTL, and VHDL and
Tcl testbenches. The 'sim build' line says put build files in the build/
directory, use up to a maximum of 8 threads, i.e. run a maximum of 8
simulations at a time, and automatically get dependency information by
parsing source files to get VHDL compile order.
With this script, running 'ttask test index=all' from the command line
will build any out-of-date files into build/, autogenerating and
building out-of-date wrappers for Tcl testbenches also into build/, then
runs all testbenches, whether written in VHDL or Tcl.
It's also possible to switch simulators without changing the build
script or sources. e.g. 'ttask test simulator=modelsim index=all' will
result in the build tool using modelsim rather than GHDL, populating
build/ with modelsim build files.
Running 'ttask test' will list testbenches the build tool 'found'
(testbenches can also be specified explicitly), and 'ttask sim index=3'
will run one of them in GUI mode. For GHDL this means that GTK Wave is
started after simulation. This works for GHDL irrespective of whether
the testbench is VHDL or Tcl.
Currently I only have the Tcl testbenches working with GHDL, but I want
to eventually get them working with other simulators as well. My
Script-tb and ttask projects are a work in progress. The ttask source
code is available at https://github.com/pdt/ttask. I haven't made my
Script-tb source code available yet though. I was in the process of
doing that, but I didn't manage to get to the point where I released the
code. Other things got my attention. But I'll be working on ttask and
script-tb again soon, and I'll be making the script-tb code available as
well.
I didn't realease script-tb sources because it's too immature. But ttask
is in a _reasonable_ state to use, so if anyone wants the feature to
easily switch simulators (e.g compare simulator performance), or easily
run self-checking testbenches in parallel, then it's available. I'm
developing under Linux, and mostly use Linux with several simulators
installed, but I've also used it a little bit under Windows as well.
Eventually I need to change my code that parses UUT VHDL sources,
because it doesn't handle generics. I'm considering maybe looking to see
if I can take part of the GHDL code to create a separate executable that
will give me the ports information. Then I'll use this executable with
GHDL, or any other simulator. I also need to look at VPI. I also want to
get my Tcl testbenches to work with Verilog as well. But of course I'll
want to use the simplest method, and I don't know what that is yet either.
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.
a Rhino-based JavaScript console would be just awesome :-P
Sounds good. If you start this you'll have to post to let us know how
you're getting on.
Regards,
Paul.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
