«

I was writing some code and decided to make it a procedure to put in a
library. I have written functions many times, but not a procedure.
This was a routine for some registers and counters internal to the
procedure and so required a clock and reset. I couldn't figure out
how to wirte it so that it would be inside a clocked process, so I
added the clock and reset to the inputs and put the clocking code
within the procedure.

That was all well and good. But when I tried to test it, none of the
internal variables that should have created registers were being
remembered. I ran a simulation and the variables were getting reset
initially, but on the next entry to the procedure they were back to
being undefined.

Do I have a basic misunderstanding about how procedures operate? I
haven't found a good reference to explain enough to figure out what I
am doing wrong.

Greg

On Nov 21, 10:34*pm, makeuptest <spamgoeshe...@yahoo.com> wrote:

>
> That was all well and good. *But when I tried to test it, none of the
> internal variables that should have created registers were being
> remembered. *I ran a simulation and the variables were getting reset
> initially, but on the next entry to the procedure they were back to
> being undefined.
>

Procedures do not inherently 'remember' the values of internal
variables or signals as you would have in a process. Instead you must
make the signal available on the interface of the procedure and hook
up a real signal to that port.

This generally means that you must actually add two signals to the
interface of the procedure: one is an 'input' to the procedure which
represents the current state of the signal; the other is an 'output'
of the procedure which represent the next state of the signal.

> Do I have a basic misunderstanding about how procedures operate?

Yes...you can't hide signals within a procedure.

Kevin Jennings

On Nov 22, 12:00*am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Nov 21, 10:34*pm, makeuptest <spamgoeshe...@yahoo.com> wrote:
>
>
>
> > That was all well and good. *But when I tried to test it, none of the
> > internal variables that should have created registers were being
> > remembered. *I ran a simulation and the variables were getting reset
> > initially, but on the next entry to the procedure they were back to
> > being undefined.
>
> Procedures do not inherently 'remember' the values of internal
> variables or signals as you would have in a process. *Instead you must
> make the signal available on the interface of the procedure and hook
> up a real signal to that port.
>
> This generally means that you must actually add two signals to the
> interface of the procedure: *one is an 'input' to the procedure which
> represents the current state of the signal; the other is an 'output'
> of the procedure which represent the next state of the signal.
>
> > Do I have a basic misunderstanding about how procedures operate?
>
> Yes...you can't hide signals within a procedure.
>
> Kevin Jennings

Yes, I finally found a reference that says variables won't retain
their values between invocations in a procedure. I guess that is
different from a process, but now that I think about it, that only
makes sense. In order to have a register created, the process would
have to pass the value out and back in.

Thanks

On 11/22/2010 2:27 PM, makeuptest wrote:

> In order to have a register created, the process would
> have to pass the value out and back in.
>

For example, see the procedure "retime" here:
http://mysite.ncnetwork.net/reszotzl/rise_count.vhd

-- Mike Treseler