«

I am trying to debug a design that uses procedures and impure
functions defined with the scope of a process. The problem I have is
in viewing these in a sensible manner.

The only way I have found is to set a breakpoint within the procedure,
at this point, the variables become visible inside the 'variables'
window, where they can then be logged.

If I try to save this view as a '.do' file and subsequently load it
into modelsim on another run, the scope has been lost and I'm required
to set up a breakpoint again etc. etc.

Is there a way around this where the deeper variables (procedure and
function scope) can be logged in a decent manner?

Thanks for any help you can give with this.

Mark

The key is to put labels on all processes.
Otherwise modelsim tracks processes by line number.
Here's an example .tcl (.do) file

add wave /test_this/*
;# top level testbench signals
add wave /test_this/uut_1/*
;# top level entity signals
add wave /test_this/uut_1/get_data/*
;# variables in the process get_data
add wave /test_this/uut_1/put_data/*
;# variables in the process put_data

Note that these waves are the "end of process" values.
To see a loop variable changes during a process,
you have to trace code.

Good luck.
-- Mike Treseler

Hi Mike,

Thanks for your reply.

I am already able to view the variables in the base scope of the
process (all processes are already named), the problem is viewing the
variables in the scope of each of the procedures.

For (a very contrived) example:

signal reduced : std_logic;
signal lala : std_logic_vector(3 downto 0);
signal foo : std_logic;

DemoProcess : process (lala, foo)
--
procedure OrReduce (
) is
variable Temp : std_logic;
begin
for i in 0 to 3 loop
Temp := Temp or lala(I);
end loop;
reduced <= Temp;
end procedure OrReduce;
--
variable topScopeVar : std_logic;
begin
topScopeVar := '0';
if foo = '1' then
topScopeVar := '1';
end if;
OrReduce;
end process DemoProcess;

Tha variable 'topScopeVar' is visible in the variables window (@
/test_this/uut_1/DemoProcess/* as would be expected), but the variable
'Temp' and procedure 'OrReduce' aren't. That is, until a breakpoint is
set within the procedure 'OrReduce'.

Now, as they are viewable once I have set and fired a breakpoint, it
stands to reason that they should be traceable before this point.

Hope that expands a bit more on what I meant.

Thanks,

Mark

"mike_treseler" <tres@fl_ke.com> wrote in message news:< alkaboutprogramming.com>...
> The key is to put labels on all processes.
> Otherwise modelsim tracks processes by line number.
> Here's an example .tcl (.do) file
>
> add wave /test_this/*
> ;# top level testbench signals
> add wave /test_this/uut_1/*
> ;# top level entity signals
> add wave /test_this/uut_1/get_data/*
> ;# variables in the process get_data
> add wave /test_this/uut_1/put_data/*
> ;# variables in the process put_data
>
> Note that these waves are the "end of process" values.
> To see a loop variable changes during a process,
> you have to trace code.
>
> Good luck.
> -- Mike Treseler

On 9 Nov 2004 01:43:32 -0800, (Mark) wrote:

>Hi Mike,
>
>Thanks for your reply.
>
>I am already able to view the variables in the base scope of the
>process (all processes are already named), the problem is viewing the
>variables in the scope of each of the procedures.
>
>For (a very contrived) example:

[snippage]

>Now, as they are viewable once I have set and fired a breakpoint, it
>stands to reason that they should be traceable before this point.

This thread might help:
http://groups.google.com/groups?thre...news.dfncis.de

Regards,
Allan

OK Mark, I see what you're saying.

Procedure variables are not stable objects
like signals or process variables.
They get popped off the stack each time
the procedure exits. You can't set up
an ADD WAVE in advance because the target object
does not exist until the first call to
the procedure. In the case of packaged
procedures there can be more than one
calling process sharing the same procedure variable.

Maybe you want to pass a process variable
to your procedure. Or just trace code if need be.

-- Mike Treseler