«

Hi newsgroup,

I have variables used in a procedure defined in a package. A process
in a testbench module is calling that
procedure.
When marking the package in Modelsim and opening the "Locals" window I
do not see any variables.

Is there some way to make them visible ?

Rgds,
Andre

On Jun 20, 3:21 am, "ALu...@web.de" <ALu...@web.de> wrote:
> Hi newsgroup,
>
> I have variables used in a procedure defined in a package. A process
> in a testbench module is calling that
> procedure.
> When marking the package in Modelsim and opening the "Locals" window I
> do not see any variables.
>
> Is there some way to make them visible ?
>
> Rgds,
> Andre

I'm not sure about this, but I believe that if you go through the
package, then there is no scope to associate with the procedure. You
need to drive down through the procedure call in your code to get into
the procedure body, so that the simulator knows for which instance you
need the local variables.

Andy

> On Jun 20, 3:21 am, "ALu...@web.de" <ALu...@web.de> wrote:

>> I have variables used in a procedure defined in a package. A process
>> in a testbench module is calling that
>> procedure.

Andy wrote:
> I'm not sure about this, but I believe that if you go through the
> package, then there is no scope to associate with the procedure. You
> need to drive down through the procedure call in your code to get into
> the procedure body, so that the simulator knows for which instance you
> need the local variables.

Yes. There are two parts to the solution.
One is an "add wave" command for each calling process.
Two is to trace code through the procedure
because that is the only time variable
local to the procedure are visible.

Note that procedures *declared* in process scope
have direct access to process variables, which
are always visible.

-- Mike Treseler

Hi,

thank you for your comments.
I think it can indeed be an advantage to use procedures declared in
the process calling them so that the variables are permanently
visible.
When declaring the procedures in a separate package the only way to
make the variables visible
is to set a breakpoint on the code line where the procedure is called
and then to step through
the code.

Rgds
Andre

On Jun 23, 5:53 am, "ALu...@web.de" <ALu...@web.de> wrote:
> Hi,
>
> thank you for your comments.
> I think it can indeed be an advantage to use procedures declared in
> the process calling them so that the variables are permanently
> visible.
> When declaring the procedures in a separate package the only way to
> make the variables visible
> is to set a breakpoint on the code line where the procedure is called
> and then to step through
> the code.
>
> Rgds
> Andre

This may be heresy, but another option is to make the procedures small
enough that you can debug them by eye. If you need a large procedure,
keep breaking it down into smaller procedures and functions until they
are small. I try to keep mine under 10 lines total if practical.
That is the Forth philosophy and it can work if you actually follow
it.

The trouble is that simulators are a PITA to use. They are slow,
require a lot of setup to generate the correct stimulus and can be
difficult to interpret when you are looking for the source of a bug.
It can be much better to code in ways that reduce the likelihood of
creating bugs. The last few passes on my recent design I chose to go
straight to the chip where I could use a scope on the real circuit
rather than try to drill down through the simulator. It worked pretty
well for the slow logic that takes a long time to run in the
simulator.

Rick