VHDL equivalent of Verilog "task"
Jim Kapcio
Is there a VHDL equivalent of the Verilog "task"?
When writing test benches in verilog , I can create a CPU read/write
task and call it multiple times. How can I do this easily in VHDL?
Thomas D. Tessier
Concurrent Procedure Calls?
I have also used the approach of one big process which makes
procedure/function calls to do the bus cycles.
TomT...
--
+------------------------ ---------------------- ----------------------+
: t2design :
: 249 Lois Drive :
: Louisville, CO 80027 :
+------------------------ ---------------------- ----------------------+
: to...@hdl-design.com * (303)665-6402 * Fax: (303)665-6431 :
+------------------------ ---------------------- ----------------------+
Peter Ashenden
Jim Kapcio wrote:
>
> Is there a VHDL equivalent of the Verilog "task"?
>
> When writing test benches in verilog , I can create a CPU read/write
> task and call it multiple times. How can I do this easily in VHDL?
The closest equivalent is a procedure. You can call a procedure from a
process. You can also write a concurrent procedure call, which is
semantically equivalent to a process containing just a procedure call.
Procedures in VHDL are less restricted than Verilog tasks. In
particular, each activation of a procedure gets its own copies of local
variables, and can interact with its caller through the parameters of
the call.
Cheers,
PA
--
Peter J. Ashenden Email: pet...@ececs.uc.edu
Visiting Scholar, Dept ECECS peter.a...@acm.org
University of Cincinnati peter.a...@computer.org
PO Box 210030 Phone: +1 513 556 4756
Cincinnati OH 45221-0030, USA Fax: +1 513 556 7326
WWW: http://www.cs.adelaide.edu.au/~petera (includes PGP public key)
Janick Bergeron
In article <34904466...@ececs.uc.edu>,
Peter Ashenden <pet...@ececs.uc.edu> wrote:
>Jim Kapcio wrote:
>>
>> Is there a VHDL equivalent of the Verilog "task"?
>>
>> When writing test benches in verilog , I can create a CPU read/write
>> task and call it multiple times. How can I do this easily in VHDL?
>
>
>Procedures in VHDL are less restricted than Verilog tasks. In
>particular, each activation of a procedure gets its own copies of local
>variables, and can interact with its caller through the parameters of
>the call.
They are less restrictive in the sense that they are re-entrant.
You did put the necessary check to detect concurrent task activation
in your Verilog code, didn't you?
They are less flexible because of the strict VHDL rules about
drivers (unless you are using a VHDL-93 simulator which support
shared variable, in which case, you have Verilog's flexibility).
The non-93 alternatives follow.
If you want your bus-functional procedures to be shared accross
several entity/architectures (which is probably the case for testbenches)
you want to put them in a pckage (you probably put them in a `include'ed
file in Verilog or accessed them using a hierarchical name - same
principle). Because they are not located inside a process (where the
signal drivers are), you will have to pass all bus signals to the
procedure using "signal" kind arguments so the procedure can access
their drivers. E.g. for a 386 bus:
procedure WRITE( WADD : in STD_LOGIC_VECTOR(15 downto 0);
DATA : in STD_LOGIC_VECTOR(15 downto 0);
signal CK2 : in STD_LOGIC;
signal ADDR : out STD_LOGIC_VECTOR(15 downto 0);
signal ADS : out STD_LOGIC;
signal RW : out STD_LOGIC;
signal READY: in STD_LOGIC;
signal DATA : out STD_LOGIC_VECTOR(15 downto 0));
If you are planning to model a 64-bit PCI bus, that can get very cumbersome
to pass all bus signals to every read/write calls. You can reduce
the size of the argument list by combining in, out and inout signals
into records.
Alternatively, you can declare the procedure *inside* a process
in which case it will have direct access to the process' drivers.
You will be able to assign to signals using side effect and therefore
have a much simpler calling syntax. For example:
process
procedure WRITE(WADD : in STD_LOGIC_VECTOR(15 downto 0);
DATA : in STD_LOGIC_VECTOR(15 downto 0))
begin
...
end WRITE;
begin
...
end process;
On the other hand, that means that you have to maintain a copy of the
procedures for each process that needs to call it. That can be solved
by preprocessing VHDL through the C preprocessor using a #include'ed file.
Alternatively, you could create a bus-functional model entity that
accepts read/write commands via an input and an output record control
signals (don't use inout, you'll have to resolve it). Cumbersome but
powerful. That's the style of BFMs generated by QuickBench so that
particular tool may take the "cumbersome" out.
--
Janick Bergeron Qualis Design Corporation Main : (503) 670-7200
Director of 5535 SW Meadows, Suite 450 Dirct: (503) 968-8544
Technology Lake Oswego, OR 97035 Fax: (503) 670-0809
http://www.qualis.com jan...@qualis.com