funtions

hi all,
I have a very simple task, which is to fill an array of data with some
binary stram I have in hand. This is needed because I need to pick up
single elements of this array and send them through a dedicated protocol
to my DUT.
To do this I wanted to use a function which takes the binary values and
write in the correct way to the array.
Unfortunately it doesn't work through ModelSim.
I attach the code:

-- declaration
....

type inoutbuf is array (0 to 300) of std_logic_vector (15 downto 0);

signal setup_buf : inoutbuf;

function fill_setup (setup_reg : std_logic_vector (23 downto 0))
return inoutbuf;

....

-- body

function fill_setup (setup_reg : std_logic_vector (23 downto 0))
return inoutbuf is
variable buf : inoutbuf;
begin
for i in 0 to 5 loop
buf (i) := (others => '0');
end loop;
buf (0) := std_logic_vector (conv_unsigned (unsigned (setup_reg
(3 downto 0)), 16));
buf (1) := std_logic_vector (conv_unsigned (setup_reg (4), 16));
buf (2) := std_logic_vector (conv_unsigned (setup_reg (5), 16));
buf (3) := std_logic_vector (conv_unsigned (unsigned (setup_reg
(16 downto 6)), 16));
buf (4) := std_logic_vector (conv_unsigned (unsigned (setup_reg
(19 downto 17)), 16));
buf (5) := std_logic_vector (conv_unsigned (unsigned (setup_reg
(23 downto 20)), 16));
return buf;
end fill_setup;

When I call it I simply type:

buf <= fill_setup (setup_val);

where buf is an inoutbuf.
Why buf is always zero????
I'm sure I'm doing a very stupid mistake, thank you all

Al



--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

Al wrote:

> Why buf is always zero????

Maybe setup_reg is zero
and that is the right answer.

I would start by declaring
the sample data array as a constant.

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
> Al wrote:
>
>
>>Why buf is always zero????
>
>
> Maybe setup_reg is zero
> and that is the right answer.
>
unfortunately is not the right answer!
> I would start by declaring
> the sample data array as a constant.
>
I did it, but didn't work. If I run modelsim step by step to check
through the function it looks like the buffer is correctly filled but
everything is "lost" on the return...why?

> -- Mike Treseler


--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

On Wed, 13 Jun 2007 11:47:45 +0200,
Al <> wrote:

>I did it, but didn't work. If I run modelsim step by step to check
>through the function it looks like the buffer is correctly filled but
>everything is "lost" on the return...why?

You're copying the return value to a signal; did you wait long
enough for the signal to update?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

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

Jonathan Bromley

Al wrote:
> Mike Treseler wrote:
>
>> Al wrote:
>>
>>
>>> Why buf is always zero????
>>
>>
>>
>> Maybe setup_reg is zero
>> and that is the right answer.
>>
> unfortunately is not the right answer!
>
>> I would start by declaring
>> the sample data array as a constant.
>>
> I did it, but didn't work. If I run modelsim step by step to check
> through the function it looks like the buffer is correctly filled but
> everything is "lost" on the return...why?
>

I declared the setup_buf as an internal variable instead of an external
signal and now it works. What I don't understand is why all the other
external signals are updated every clock pulse while this one is not.
I miss something...

Just to give more details I use a procedure overloading in one process
and I have a big set of procedures which do all the functions I want. At
the very bottom of the procedure nesting there are very basic procedure
to set_bit or reset_bit which are overloaded with actual signal I want
to set. So I don't understand why all those procedures are working
correctly while for this one I had to use a local variable?
My main process has a wait state so I don't understand how can it be
possible that all other signals are updated.

Thanks a lot for clarifying my confusion!
Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

Jonathan Bromley wrote:
> On Wed, 13 Jun 2007 11:47:45 +0200,
> Al <> wrote:
>
>
>>I did it, but didn't work. If I run modelsim step by step to check
>>through the function it looks like the buffer is correctly filled but
>>everything is "lost" on the return...why?
>
>
> You're copying the return value to a signal; did you wait long
> enough for the signal to update?
How long will it take to a signal to be updated? I'm talking about
testbench and I'm actually editing the "stimulus".
As far as I knew signals are updated at the end of the process...but as
I mentioned in my previous post, I don't understand why some other
signals are updated while this one is not.
Thanks for your help

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

On Wed, 13 Jun 2007 12:44:04 +0200,
Al <> wrote:

>Jonathan Bromley wrote:
>> You're copying the return value to a signal; did you wait long
>> enough for the signal to update?
>How long will it take to a signal to be updated?

One delta cycle. In effect, when you write to a signal, the
signal update is postponed until *all* process activity
(not just the process that wrote the signal) has reached a
wait statement or hit a sensitivity list. This takes
zero nanoseconds, but one VHDL delta.

>As far as I knew signals are updated at the end of the process...

not quite, see above.

>I mentioned in my previous post, I don't understand why some other
>signals are updated while this one is not.

OK, so it seems you've now created an intermediate
variable that *is* updated..

int_var := some_function(...);
sig <= int_var;

Do you *still* find that "sig" is not updating? If so,
the most likely explanation is that some code later in the
process, but running in the same delta, is writing to
"sig" all over again. The second scheduled update to "sig"
will cancel the first.

Try doing "wait for 5 ns;" immediately after writing
your signal. If (as I suspect) that causes the signal
to take the right value for 5ns and then drop back to
all-zero, then you've got another piece of code - later
in the same process - making an unwanted write to the signal.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

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

Jonathan Bromley

Al wrote:

> How long will it take to a signal to be updated? I'm talking about
> testbench and I'm actually editing the "stimulus".

To update testbench signals, I hide the details
in procedures like these:
-------------------------------------------------------------------------------
procedure tic is
begin
wait until rising_edge(clk_s);
end procedure tic;
-------------------------------------------------------------------------------
procedure set_bit (signal arg_s : inout std_ulogic) is
begin-- skip tic if already set
if arg_s /= '1' then
arg_s <= '1';
tic;
end if;
end procedure set_bit;
-------------------------------------------------------------------------------
procedure clr_bit (signal arg_s : inout std_ulogic) is
begin -- skip tic if already clear
if arg_s /= '0' then
arg_s <= '0';
tic;
end if;
end procedure clr_bit;
-------------------------------------------------------------------------------
procedure toggle (signal arg_s : inout std_ulogic) is
begin
clr_bit(arg_s); -- costs no time if already low
set_bit(arg_s);
clr_bit(arg_s);
end procedure toggle;
-------------------------------------------------------------------------------


-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
> Al wrote:
>
>
>>How long will it take to a signal to be updated? I'm talking about
>>testbench and I'm actually editing the "stimulus".
>
>
> To update testbench signals, I hide the details
> in procedures like these:
> -------------------------------------------------------------------------------
> procedure tic is
> begin
> wait until rising_edge(clk_s);
> end procedure tic;
> -------------------------------------------------------------------------------
> procedure set_bit (signal arg_s : inout std_ulogic) is
> begin-- skip tic if already set
> if arg_s /= '1' then
> arg_s <= '1';
> tic;
> end if;
> end procedure set_bit;
> -------------------------------------------------------------------------------
> procedure clr_bit (signal arg_s : inout std_ulogic) is
> begin -- skip tic if already clear
> if arg_s /= '0' then
> arg_s <= '0';
> tic;
> end if;
> end procedure clr_bit;
> -------------------------------------------------------------------------------
> procedure toggle (signal arg_s : inout std_ulogic) is
> begin
> clr_bit(arg_s); -- costs no time if already low
> set_bit(arg_s);
> clr_bit(arg_s);
> end procedure toggle;
> -------------------------------------------------------------------------------
>
>

I'm using the same approach (that I actually "stole" from you). The only
difference between the other signals and the one it was not updating is
that all the others are overloaded in the procedures, while the other
was set in the body of the process.
Based on what Jonathan Bromley wrote in the previous post

> One delta cycle. In effect, when you write to a signal, the
> signal update is postponed until *all* process activity
> (not just the process that wrote the signal) has reached a
> wait statement or hit a sensitivity list. This takes
> zero nanoseconds, but one VHDL delta.

I expect that if some signals are updated that means that all signals
must be updated in the same delta. Again this confuses me and I don't
really understand why my code behave that way.
Thanks again and sorry for my slowness!
Al


--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al

Al wrote:

> I'm using the same approach (that I actually "stole" from you). The only
> difference between the other signals and the one it was not updating is
> that all the others are overloaded in the procedures, while the other
> was set in the body of the process.

Maybe more than one process is driving the stim signals.
I like to use one process for the clock, with a finite wait
each loop, and one main process for stim/verify with
synchronous waits as needed and an infinite wait at the end.

-- Mike Treseler

Mike Treseler