Using a Verilog macro in an include statement?
rob...@my-deja.com
Is there a way to pass in a MACRO definition to a testbench and then use
that MACRO in an include statement within the testbench.
Here's a generic example of the command followed by the contents of the
testbench and include file:
vlog +define+TEST_NAME=test1 testbench.v
--- testbench.v
module test;
`include `TEST_NAME.v
`TEST_NAME;
endmodule
---
--- test1.v
task test1;
begin
...
endtask
---
If it's not possible, is there a recommendation on how to do this
otherwise. Basically, I want to pass in the task name (which corresponds
to the filename) and have that file included in the testbench so I can
then make a call to the Verilog task.
Thanks.
Rob
rob...@teleport.com <-- please respond here if using email
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Sreekanth Godey
module test;
`ifdef TEST1
`include "test1.v"
`endif
`ifdef TEST2
`include "test2.v"
`endif
endmodule
and write a script (let us name it run_test) which has the call for vlog as
follows ....
vlog +define+$1 testbench.v
so at the prompt,
%s> run_tests TEST1 ----> will runs your test1.v vectors
%s> run_tests TEST2 ----> will runs your test2.v vectors
Hope this helps !!!
Regards,
Sreekanth
Tom Loftus
What I have done in this situation is to always include
a fixed name like:
module test;
`include "test_procedure.v"
endmodule
Then, at run time, in my script which starts my
simulation, I create a link to the desired code:
test_procedure.v -> test1.v
I invoke my simulation like:
run_sim test1
To answer your question, I have not gotten a macro definition
to work in an include statement. I have gotten it to
work in task calls like
$readmemh(`ROMFILE,rom_array);
The only trick here is to make sure your macro definition
properly escapes the quotes so that the expanded
macro is syntactically correct.
Tom Loftus
Hughes Network Systems
rob
Every time you add of delete a test you have to update this file.
Your suggestion is exactly the way I used to do this, but I've since modified
the testbench so that it includes a static file name (i.e. test.v) that is
dynamically updated via a makefile before simulating the design. The problem
with this is that if I want to run multiple simulations in the same directory,
there's a large potential for the static file to contain the wrong test name
with multiple processes writing to that file.
My latest thought is to have the makefile copy of the testbench file to a new
filename (based on the test name) and then use perl to dynamically update the
`include directive in the testbench to include the right test name. It's kind
of involved, but it's the cleanest and simplest way I can think of to automate
this process.
What do you think?
rob
WindowsNT environment. My requirement is that the solution needs to work
for both WindowsNT and *Unix*.
The other problem I'm having is that I need the ability to run more than
one simulation in the same area.
Any other ideas?
Thanks!
Michael Thompson
We have the same situation at our shop. We've found that Perl scripts
will do what Tom is suggesting for both NT and Unix. Our NT users also
use something called "OpenNT", and we've found that bourne shell scripts
work under both OpenNT and Unix.
Good luck,
--- Mike Thompson
MOSAID Technologies
Utku Ozcan
> We have the same situation at our shop. We've found that Perl scripts
> will do what Tom is suggesting for both NT and Unix. Our NT users also
> use something called "OpenNT", and we've found that bourne shell scripts
> work under both OpenNT and Unix.
>
> Good luck,
> --- Mike Thompson
> MOSAID Technologies
I will talk about Verilog-XL.
It is impossible to pass macro to `include commands within Verilog
environment. The only solution within Verilog-XL is the solution
Sreekanth proposed. The other one is, as other repliers informed,
to use an external tool like Perl.
By the way, has anyone used following command in Verilog-XL?
`undef verilog
Utku
--
I feel better than James Brown.
pet...@scimba.dolphinics.no
> If it's not possible, is there a recommendation on how to do this
> otherwise. Basically, I want to pass in the task name (which corresponds
In my early Verilog days I used to do a similar thing, substitute test
bench files by links and other tricks. Now I feel more comfortable
with a more test-bench centric approach. I have a separate directory
for each test-bench. The behave files reside in a directory relative
to each test bench, e.g.
design-root
behave
tests
tb1
tb2
tb3
...
tbn
Each test-bench has a script which will run the test (which could be a
link to a common script or a tiny script which calls a shared script)
and the design files are read using a relative path ../../behave/*.v
or similar.
This has a couple advantages like your verilog.log file, signalscan
trn, and Chronologic simv files will not be overwritten if you run
several tests concurrently, you can also switch to gate level files by
using ../../target_tech/*.v. Running all the tests is a matter of
iterate over all the various tests directories and start each
test-bench. The files reside under CVS and there is no need to make
script to shuffle test-bench files around using this method. Just
check out the files and run.
Of course you might experience problems with different type of
directory path specification across various platforms using this
method.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Keighley Ross
>This works great for *unix* systems, but unfortunately fails in a
>WindowsNT environment. My requirement is that the solution needs to work
>for both WindowsNT and *Unix*.
>
>The other problem I'm having is that I need the ability to run more than
>one simulation in the same area.
>
>Any other ideas?
Why do you need to run more than one simulation in the same area?
Do you mean a different test?
I've had good success on a few projects using a unique directory
for *every* test, where is a "test" is the set of components
around the DUT, the stimulus, and the expected result. In this way,
the directory contains only a small number of files:
- Makefile, a small file that includes a bunch of common stuff
and a few lines of defines specific to this test
- test.v and/or rom.v - the stuff that specifies the stimulus
- expect.pat - if the expected results are specified by an output pattern
- test.out - the simulation output from the last time the test was run
In practice, there were some history files and some run-time temporaries,
too. All of the design, and any common testbench code were NOT in this
directory. This method avoids having to edit the names in the `includes.
I don't know about NT, but this was able to support three different
Verilog simulators (using different make targets). Gnu make is available
in both environments.
Maybe this approach could work for you.
-------------------------------------- Keighley Ross ----------------
kr...@intersil.com Design Systems
407-724-7200 Intersil Corporation
www.intersil.com Melbourne, Florida