Interesting, Larry.
I'm new to Icarus, just started using it recently. Prior to that, I've used Aldec tools for years. The process is a lot different - at least how I've use the tools (that is, using test benches, single stepping and breakpoints in code)
How are you running lint? The only linter I've spent time with, is splint and never figured out, how to apply it to verilog. Recently, Aldec has added a linter to their product line. If you don't mind the cost, it's probably pretty good. I don't have the doe for that, so am interested in your method.
My make skills are weak, so I have to decode some of what you've written. Also, what is awk? That's new to me.
regards,
gene
----- Original Message -----
From: Larry Doolittle
Date: Wednesday, May 21, 2008 12:51 pm
Subject: gEDA-user: Verilog, testbenches, and Makefiles
To: gEDA user mailing list
> I just finished cleaning out some lint on some Verilog code
> and infrastructure, and thought it might be nice to share some
> of my techniques.
>
> Context is Icarus Verilog, gtkwave, and running regression-style
> testbenches on production synthesizable FPGA code.
>
> Suppose we have a synthesizable foo.v, that instantiates a module
> from bar.v. For consistency, put the testbench for foo in foo_tb.v.
> Make sure foo_tb.v prints out either PASS or FAIL.
> The heart of the Makefile is a set of four general rules:
>
> %_tb: %_tb.v
> iverilog -Wall -DSIMULATE ${VFLAGS_$@} $^ -o $@
>
> # Generic regression test
> %_check: %_tb testcode.awk
> vvp $< | awk -f $(filter %.awk, $^)
>
> %.vcd: %_tb
> vvp $<
>
> # Useful for those testbenches that have a corresponding .sav file
> %_view: %.vcd %.sav
> gtkwave $^
>
> To make this apply properly to foo, all you need to add is:
>
> foo_tb: foo.v bar.v
>
> At which point "make foo_check" will compile and run the testbench,
> using the following testcode.awk program to signal success or failure
> to make(1):
>
> --cut here--
> # very general processing of vvp output to set a return code
> # since apparently Verilog running inside vvp does not have
> # a way to affect that directly
> BEGIN{code=1}
> /PASS/{code=0}
> {print $0}
> END{exit(code)}
> --cut here--
>
> If you have extra compile flags peculiar to this testbench, perhaps
> for floating point support, you can add them like this:
>
> VFLAGS_foo_tb = -m va_math
>
> When the testbench works properly, add "foo_check" to the all: line
> of the Makefile. If you use gtkwave to inspect the waveforms for
> problems, on your way to developing a true PASS/FAIL output of the
> testbench, save the gtkwave configuration in foo.sav. Then you can
> recompile, rerun the simulation, and bring up a fresh gtkwave screen
> with the single command "make foo_view".
>
> Finally, the Makefile can end with a superset of:
>
> clean:
> rm -f *_tb *.vcd
>
> That's it! I started using Icarus and Makefiles heavily about four
> years ago, and have gradually worked my way up to this point. This
> template is compatible with the pristine-source paradigm using VPATH.
> My current project has ten _check targets for the various components
> that make up the final design; five of them are exactly as presented
> above, the other five have more specialized post-processing.
>
> I welcome discussion and suggestions for improvement.
>
> - Larry
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>