Is it possible to watch variables and signals during debug?

[Dufour]

I'm new in vhdl programming and I'm writing simple programs (I'm using
xilinx ise webpack 7.1). When I debug my programs I would to watch the value
of some variables and signals (they are not input/output), but I can't. By
working with ISE I can see that the Test Bench Waveform permits to watch
only input and output signals. How can I do?
Thank you.

 

[Mike Treseler]

I'm new in vhdl programming and I'm writing simple programs (I'm using
xilinx ise webpack 7.1). When I debug my programs I would to watch the value
of some variables and signals (they are not input/output), but I can't.

I write a testbench and use modelsim commands to display the waves.
add wave * ;# Signals
add wave /$mytb/main/* ;# Test variables
add wave /$mytb/dut/main/* ;# UUT variables

See the testbench here for more details:
http://home.comcast.net/~mike_treseler/

-- Mike Treseler

 

[KJ]

I write a testbench and use modelsim commands to display the waves.
add wave * ;# Signals
add wave /$mytb/main/* ;# Test variables
add wave /$mytb/dut/main/* ;# UUT variables

Is there a way to add variables to the wave 'after the fact'? By that I
mean, if I'm at sim time 1 ms and want to see the entire history of some
variable. I use the log -r /* in my Modelsim testbench script which allows
signals to be added to the wave window and show the entire history but I
haven't found how to do that with variables.

KJ

 

[Mike Treseler]

Is there a way to add variables to the wave 'after the fact'? By that I
mean, if I'm at sim time 1 ms and want to see the entire history of some
variable. I use the log -r /* in my Modelsim testbench script which allows
signals to be added to the wave window and show the entire history but I
haven't found how to do that with variables.

Me neither. However, sims on signal-less DUTs
are so speedy that just adding the waves and restarting
may be fast enough.

-- Mike Treseler

 

[Ricardo]

You may start a simulation, select signals and vaiables you wish to
see, then save a "wave.do" file.

Next, you may take a look at auto-generated scripts for modelsim
generated by ISE. Edit it. change the line "add wave *" (something like
this) for "do wave.do"

They are generated in the project folder (the *.FDO). You may edit them
and change the way ise call modelsim (right click, edit properties and
select a custom *.do file: you will find this there.

You must save your file with another *.do extension (do not overwrite
wave!!!). It may look annooying at firt look, but you will get familiar
to it.

Sds,

Ricardo

KJ escreveu:

 

[KJ]

You may start a simulation, select signals and vaiables you wish to
see, then save a "wave.do" file.

Next, you may take a look at auto-generated scripts for modelsim
generated by ISE. Edit it. change the line "add wave *" (something like
this) for "do wave.do"

They are generated in the project folder (the *.FDO). You may edit them
and change the way ise call modelsim (right click, edit properties and
select a custom *.do file: you will find this there.

You must save your file with another *.do extension (do not overwrite
wave!!!). It may look annooying at firt look, but you will get familiar
to it.

I'm not sure I understand how that addresses my question, could you
clarify. The scenario is that I'm already into a simulation (say
t=1ms) and I find a problem that I need to investigate. What I would
normally do is...

- Add the signal being flagged as a problem by the testbench to the
wave window so that I can see the entire history of what went on with
that signal up to now where I see that there is the problem that I'm
trying to fix.
- Iteratively add signals to the wave window to backtrack through the
logic until I get to the point where I can see in the source code where
the root cause error is.

Generally speaking, the first point where the testbench detects a
problem is reporting only the first detected symptom of something gone
wrong and is not the root cause of the problem. That root cause
problem that started the chain of events happened at some earlier time
in the simulation so you need to have the history of each of those
signals in order to fix the problem. With the Modelsim log -r /*
command prior to run I can capture that entire history for later
display in the wave window when I so choose. But if you replace the
word 'signal' with 'variable' in all of the above I haven't found out
how to display the history of any variables that led up to the current
time.

I think what you've described is a way to save the list of signals and
pull them back up again on a subsequent simulation but that's not what
I was looking for.

KJ

 

[KJ]

However, sims on signal-less DUTs are so speedy

Do you have any reference designs that demonstrate this? I wrote one
for a simple counter a while back using signals and then variables and
I think I remembered measuring about a 10% improvement using variables.
At the time I didn't feel that 10% was worth the risk of having to
restart sim just to see history on variables that are in the logic path
towards the root problem but I also didn't think a counter was
necessarily representative of the extensive use that you make with
variables either.

I realize that the entity boundaries will be signals that can be waved
to backtrack through during debug, but I know I also tend to wave
internal signals within the architecture during that debug time.

that just adding the waves and restarting may be fast enough.

Agreed, depending on what is being test, it may be fast enough to
restart. But even so, the time lost doing so would need to be deducted
from the 10% speedup (or whatever that number that you see).

KJ

 

[Dufour]

"Mike Treseler" :

I write a testbench and use modelsim commands to display the waves.
add wave * ;# Signals
add wave /$mytb/main/* ;# Test variables
add wave /$mytb/dut/main/* ;# UUT variables

See the testbench here for more details:
http://home.comcast.net/~mike_treseler/

-- Mike Treseler

I'll try.
Thank you very much.

 

[Mike Treseler]

Do you have any reference designs that demonstrate this?

No, I've just noticed that testbench elaboration
and run times increase with the number of signal bits
in the DUT.

I wrote one
for a simple counter a while back using signals and then variables and
I think I remembered measuring about a 10% improvement using variables.

That sounds about right if the output register
is the only register. However, a complex design entity
has many more internal registers than output registers.

I write a command (do) file that lights up the processes I am working
on, and just run that when I need to look at waves.
You are correct that this is something I wouldn't
have to do if everything I needed to look at were a signal.
But then, writing the command file is a simple task
and typing "do mywaves.do" isn't much harder
than typing "add waves * "

At the time I didn't feel that 10% was worth the risk of having to
restart sim just to see history on variables that are in the logic path
towards the root problem

Certainly not worth modifying working code,
but something to consider for next time.
I am certain that the speedup is better
than 10% for processes with hundreds
or thousands of internal register bits.

but I also didn't think a counter was
necessarily representative of the extensive use that you make with
variables either.

I agree. A better speed battle might be a single
variable array of 1000 prescale counters vs
a generate loop or instances of the same counters.

I realize that the entity boundaries will be signals that can be waved
to backtrack through during debug, but I know I also tend to wave
internal signals within the architecture during that debug time.

I find that looking at the output
waves is often enough to debug a problem
using code inspection or by tracing code
and variables. These debugging
techniques much less useful for a
multiprocess design.

Agreed, depending on what is being test, it may be fast enough to
restart. But even so, the time lost doing so would need to be deducted
from the 10% speedup (or whatever that number that you see).

My best argument is above.
I don't really ever have to restart to see waves.


-- Mike Treseler

 

[Ajeetha]

Sometime back I faced similar issue, and IIRC - I managed to add VHDL
variables (those inside processes, and named processes to be specific)
by explicitly naming them i.e.

p1 : process
variable a_var : bit;
begin
wait;
end process p1;

I do:

log /top/dut/p1/a_var

May be that limitation is still around! It is such a pain to list all
named variables. VCS-MX (and its GUI - DVE) is lot easier in this
aspect - IMHO. Not sure what NC does.

HTH
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
h**p://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

 

[Mike Treseler]

log /top/dut/p1/a_var

I just tried it for a whole process, and that works too!
For example:

log /top/dut/p1/*

Covers all the variables in p1.
Thank you very much for sharing this tip!

May be that limitation is still around! It is such a pain to list all
named variables.

If Modelsim had the problem, it is solved at or before version 6.2a.

-- Mike Treseler

 

[Ajeetha]

Mike,
Glad that someone was able to help the all time helper - Mike

log /top/dut/p1/*

Covers all the variables in p1.

BTW - what I was indeed referring to (from my original tests, didn't
verify it recently) was - issue with unnamed prcoesses, but I guess
even VCSMX has that issue per-se. Anyway I personally name all my
prcoesses and IMHO that's the right way.


Regards
Ajeetha, CVC

 

[Mike Treseler]

Anyway I personally name all my
processes and IMHO that's the right way.

Me too.
Modelsim uses a line number otherwise.

one : process(reset, clock) is ...

There, that didn't take long

-- Mike Treseler