Passing Signals to Procedure

[Analog_Guy]

I am having difficulty with what seems to be a very simple thing.

I want to code a generic testbench procedure to automatically check any
n-input combinatorial function in my design.

Currently, I used a quick and dirty way just to get the automatic
checking working. For example, I have a separate combinatorial
procedure to handle 6-input functions, and another to handle 9-input
functions. This works fine, but now a requirements changes converted
one of my outputs to a 7-input function. With my current approach,
this means I now have to code a separate procedure to handle 7-input
combinatorial functions. This does not seem like a good way of
handling things.

What I would like is if someone knows how to pass a variable number of
input signals to a generic procedure?

I know I can send an unconstrained vector to a procedure, and use a
'range to determine the length inside the procedure, but am not sure if
this would work with a concatenated vector of inputs? I think I would
have to declare unique vectors for each of my different combinatorial
functions. Example:

Current Approach
================
test_comb_6ip(ip_1, ip_2, ip_3, ip_4, ip_5, ip_6, output_function);

Can I do this?
==============
signal vector_6ip : STD_LOGIC_VECTOR(5 DOWNTO 0);
vector_6ip <= ip_1 & ip_2 & ip_3 & ip_4 & ip_5 & ip_6;
test_comb(vector_6ip, output_function);

I have not yet convinced myself that the second approach will work?

Note that the input signals are declared as INOUT in my PROCEDURE, so
that I may force the various input combinations on my output_function.

Any help would be appreciated.

 

[Reiner Huober]

When you say functions, you mean procedures, don't you.

As you say, you can declare an array (natural range<>) of type. You can
use concatiation or aggregates:

test_comb((ip_1,ip_2,ip_3,ip_4,ip_5,ip_6),output_function);

If you use inout signals, you cannot assign to vector_6ip, which is
another signal. You must pass the signals you mean.

Hubble.

 

[Mike Treseler]

I want to code a generic testbench procedure to automatically check any
n-input combinatorial function in my design.

Functions are timeless and can be verified using assertions:

assert my_function("10101010") = 170
report "my_function: error in case 170.";

What I would like is if someone knows how to pass a variable number of
input signals to a generic procedure?

I would leave time and signals out of it.
Just loop through a constant array of
stim and expected values.


-- Mike Treseler

 

[Analog_Guy]

Functions are timeless and can be verified using assertions:

assert my_function("10101010") = 170
report "my_function: error in case 170.";


I would leave time and signals out of it.
Just loop through a constant array of
stim and expected values.


-- Mike Treseler

For a 9-input combinatorial gate, wouldn't I have to create a constant
array with 512 elements? I wanted to cycle through every combination
of inputs. I was just trying to implement a 9-bit counter in a
procedure, whereby ip_1 <= count(8), ip_2 <= count(7), etc.. I thought
that by passing an unconstrained array, I could make a generic width
counter to automatically adapt to the number of inputs. I just can't
figure how to send the variable number of inputs to the procedure.

 

[Mike Treseler]

For a 9-input combinatorial gate, wouldn't I have to create a constant
array with 512 elements?

Yes, to cover n inputs you would need
2**n constant vectors of expected data
for the assertion.

I wanted to cycle through every combination
of inputs. I was just trying to implement a 9-bit counter in a
procedure, whereby ip_1 <= count(8), ip_2 <= count(7), etc.. I thought
that by passing an unconstrained array, I could make a generic width
counter to automatically adapt to the number of inputs. I just can't
figure how to send the variable number of inputs to the procedure.

I would use an unconstrained unsigned arg then
declare a variable of the proper length in the process:
variable vec : unsigned(arg'range) := arg;

Or you could use access types (pointers). See:
http://groups.google.com/groups?q=vhdl+load_test_data

-- Mike Treseler