package containing a global signal and a proc whic modifies it

[Ken Cecka]

Hi All,

I'm trying to set up a testbench, and for various reasons, I'd like to have
a package which contains some global signals and some procedures which can
be used to control those signals. When I try to do this, it is crashing
fuse (the xilinx simulation compiler). This may simply be a bug in their
compiler, but I thought I'd ask here first to see if the code I'm using is
correct. I've boiled it down to the minimal test case copied below. If
the "sig <= '1'" line is commented out, it compiles, but with that line
included, fuse crashes.

Ken

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

PACKAGE pkg IS
SIGNAL sig : STD_LOGIC;
PROCEDURE proc;
END pkg;

PACKAGE BODY pkg IS
PROCEDURE proc IS
BEGIN
sig <= '1';
END proc;
END package BODY pkg;

ENTITY ent IS
END ent;

USE WORK.pkg.ALL;

ARCHITECTURE model OF ent IS
BEGIN
PROCESS
BEGIN
proc;
END PROCESS;
END;

 

[Ken Cecka]

Obviously a crash is bad :-( but your code is incorrect. Any signals
which are read or assigned in a procedure in a package must be on the
parameter list. So you need

Rats. That's exactly what I was hoping to avoid. Thanks for setting me
straight.

Ken

 

[Alvin Andries]

Obviously a crash is bad :-( but your code is incorrect. Any signals
which are read or assigned in a procedure in a package must be on the
parameter list. So you need

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

PACKAGE pkg IS
SIGNAL sig : STD_LOGIC;
PROCEDURE proc (signal s : out std_logic);
END pkg;

PACKAGE BODY pkg IS
PROCEDURE proc(signal s : out std_logic) IS
BEGIN
s <= '1';
END proc;
END package BODY pkg;

ENTITY ent IS
END ent;

USE WORK.pkg.ALL;

ARCHITECTURE model OF ent IS
BEGIN
PROCESS
BEGIN
proc(s => sig);
END PROCESS;
END;


regards
Alan

One solution is to have the procedure declared inside the architecture: this
way you can access all the signals without having to pass them. The downside
is that your architecture code won't be as neat as you'd like.

Regards,
Alvin.

 

[Ken Cecka]

Mike Treseler's testbench examples show a reasonable compromise.
His package exports procedures with signal parameters as Alan Fitch
showed.

But to keep the main process using them clean, he overrides these
procedures, locally to the process, with parameterless procedures. These
have visibility to all the signals the process has, and simply call the
package procedures, passing these signals as appropriate.

My goal was to be able to write a bunch of standalone testbenches that are
fairly terse and decoupled from the full signal list, and have a large
library of useful test functions in a package.

Your (Mike's) suggestion sounds like it would solve my problem, although it
still means I'd have to replicate the wrapper procs in each of my
testbenches.

The compromise I settled on was to create a record type in my package which
contains all the signals. I tie the record to the DUT in a wrapper
component, then instantiate the wrapper in my testbenches and pass the
record to all the procs.

It's still a little ugly because I have to tristate the whole record (have
to pass it around through INOUT ports), but it achieves my goal of having
terse testbenches with very little copied code.

Ken

 

[Mike Treseler]

Mike Treseler's testbench examples show a reasonable compromise.
His package exports procedures with signal parameters as Alan Fitch
showed.

This one: http://mysite.verizon.net/miketreseler/proc_overload.vhd
overloads a signal parameter from a packaged procedure,
but this is a trivial example.

This one: http://mysite.verizon.net/miketreseler/test_uart.vhd
Is a more complete testbench, but uses
local (unpackaged) procedures with direct (parameterless) access.

-- Mike Treseler