funtions

A

Al

Guest
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 wrote:

Why buf is always zero????
Click to expand...
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 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
Click to expand...
through the function it looks like the buffer is correctly filled but
everything is "lost" on the return...why?

-- Mike Treseler
Click to expand...

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
 
On Wed, 13 Jun 2007 11:47:45 +0200,
Al <alessandro.basili@cern.ch> 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?
Click to expand...
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
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?
Click to expand...
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
 
Jonathan Bromley wrote:
On Wed, 13 Jun 2007 11:47:45 +0200,
Al <alessandro.basili@cern.ch> 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
Click to expand...
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
 
On Wed, 13 Jun 2007 12:44:04 +0200,
Al <alessandro.basili@cern.ch> 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?
Click to expand...
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...
Click to expand...
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.
Click to expand...
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
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".
Click to expand...
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 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;
-------------------------------------------------------------------------------
Click to expand...
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.
Click to expand...
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 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.
Click to expand...
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
 
On Wed, 13 Jun 2007 12:17:20 +0200,
Al <alessandro.basili@cern.ch> wrote:

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...
Click to expand...
Can you post the process code that calls the function?
I'm really confused about what your problem might be.
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top