FPGA Central

Hello,

How do I compactly replace the group of statements like this all over
the place in a large testbench and a similar one for a regrd? Do I use
a function or procedure? I thought both of those could not have wait
statements in them?

regwr <= '1';
wait for 75 ns;
regwr <= '0';
wait for 75 ns;

Thanks in advance.

Salman

On 5 Apr 2005 08:09:28 -0700, "Salman"
<[email protected]> wrote:

>How do I compactly replace the group of statements like this all over
>the place in a large testbench and a similar one for a regrd? Do I use
>a function or procedure? I thought both of those could not have wait
>statements in them?
>
> regwr <= '1';
> wait for 75 ns;
> regwr <= '0';
> wait for 75 ns;

Use a procedure.

Procedures can have wait statements; functions cannot.

If the procedure is declared locally within the process that
uses it, you can write from it to signals that do not appear
in its parameter list. This is often convenient for simple
jobs. For example, your code could be a simple parameterless
procedure...

TestGenerator: process

procedure PulseRegWr is
begin
regwr <= '1';
wait for 75 ns;
regwr <= '0';
wait for 75 ns;
end;

begin
...
PulseRegWr;
...
end process;

However, if you choose to put the procedure into
a package or into the architecture, then any signals it
drives should be passed to it as parameters of "signal"
class. For example, your procedure could be coded thus:

procedure PulseStrobe(signal WrStb: out std_logic) is
begin
WrStb <= '1';
wait for 75 ns;
WrStb <= '0';
wait for 75 ns;
end;

and you might call it thus:

...
PulseStrobe(regwr);
...

The advantage of this is that you may be able to use the same
procedure to do more than one thing, by getting it to work
on different signals. The downside is that it is of course
more verbose to call the procedure, because you must pass it
all the signals it will manipulate.

Consider designing your procedures at a somewhat higher level
of abstraction than merely twiddling a signal. For example,
you could create a "write a register" procedure with two
parameters - one to specify which register is to be written,
and the second to specify the data value it should write.

Consider also adding parameters to configure the time
delays that the procedure body will use. You can pass
parameters of type "time" to a procedure, and you can use
named association of procedure parameters. When you carry
this idea to its conclusion, you can end up with a
"transaction level" view of your testbench in which your
main stimulus generator code does stuff like...

Stimulus: process
constant ControlRegAdrs: std_logic_vector := X"3FE8";
...
procedure WriteToRegister (...) is ...;
begin
...
WriteToRegister (
address => ControlRegAdrs,
data => X"AA",
setupTime => 10 ns,
strobeTime => 20 ns,
holdTime => 5 ns
);
...

This is much nicer because concerns are separated well: the
WriteToRegister procedure fusses with all the irritating detail
about which signal to wiggle at what time, and the main process
simply calls it with the appropriate set of values and expects
to have the job done.

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.