Why are Variables so hard to monitor? 
Author Message
 Why are Variables so hard to monitor?

Correct me if I'm wrong but waveform windows and list windows only work for
signals.
Watch windows seem to be required to monitor variables.

Why is this so?

Has anyone had success/problems with monitoring variables with Active-VHDL?
(other than me:)

Steve



Sat, 28 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:

> Correct me if I'm wrong but waveform windows and list windows only work for
> signals.
> Watch windows seem to be required to monitor variables.

> Why is this so?

*** The signal structure is static during simulation. ***
Signals have a static structure once the design is elaborated
(say: setup for simulation). E.g., all signals have a known type and
size; there are no new signals during simulation nor are any removed
from the design at any simulation time. It's therefore easy to statically
define a table (waveform, list, ...) with all signals in rows/columns and
the simulation time in the other dimension.

*** There is no static variable location (in general). ***
Variables are dynamically created and removed. The variables with the
longest life time are those defined in a process (they live during the whole
simulation time). Variables defined in procedures and functions only live
during the execution of the respective subprogram. Once the procedure/function
terminates, the variable dies.
Even if one says: "I want to trace variable V in function F", this can't
be solved in a general way. Consider the case where function F is called at
two different places or even worse, function F is called recursively
(i.e., F calls itself), one has no clue which call level/location is to be
traced.

Quote:

> Has anyone had success/problems with monitoring variables with Active-VHDL?
> (other than me:)

My pragmatic approach
- for signals use waveforms or lists or any time-ordered display/report
- for variables use "printf-debugging" technics

What is printf-debugging?
- addoption from C programming language where one prints the values to be
  traced by the printf(...) function

It's common practice to add reporting code to the functional code.
This reporting code prints control flow information and relevant variable
values.

This is especially useful in concurrent environments like VHDL simulation
models. In contrast to the de{*filter*} (which jumps from one end to the other
when it reaches a wait statement), the reporting code gives you an exact
report of the activities. You do not have to browse through the entire
source code to reach the rigth place to set a breakpoint ...

Drawbacks of printf-debugging in vhdl
- no direct support from vhdl, i.e., one needs a package providing
  reporting code for the respective objects to be traced (e.g., to_string()
  functions for all types...)
- the code to be debugged must be recompiled after a change (e.g., when
  you whish to place some reporting code, you have to add it in the code
  *before* compilation
- this approach needs some discipline, e.g., the reporting code should be
  marked somehow, so it can be removed once it is obsolete
- the C-like preprocessor is not available (by default), therefore,
  such code can't be just masked out by a "define" (there are of course
  solutions for that: generics or package constants to turn reports on/off
  and leave the reporting code in the functional code; additional, synthesis
  has to be masked by pragmas...)

Even the drawback list is quite big, the benefit of being able to get
the required information in a suitable way is worth the effort.
The result is
A) generated    (not visual inspection in the de{*filter*})
B) reproducible (you get a report which can be read by anyone, well, almost...)
C) and therefore more reliable

Maybe, I (or someone else) should provide a debugging vhdl package sometime
which supports printf-debugging...

Idea: provide a perl script that scans through a vhdl design, extracts all
      type definitions and creates an ad-hoc package with a
      to_string() function for all of these types and a trace() function
      which takes a string and writes it to a file/stdout or uses
      an assert/report statement for report.
      A minimal solution could be a package that provides support for
      standard types, ieee types and arithmetic logic.

--
Andreas Gieriet

(Please replace "nospam" by "pobox" in the return address,
 which has been altered to foil junk mail senders)



Sat, 28 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:

. . .
> Maybe, I (or someone else) should provide a debugging vhdl package sometime
> which supports printf-debugging...

> Idea: provide a perl script that scans through a vhdl design, extracts all
>       type definitions and creates an ad-hoc package with a
>       to_string() function for all of these types and a trace() function
>       which takes a string and writes it to a file/stdout or uses
>       an assert/report statement for report.
>       A minimal solution could be a package that provides support for
>       standard types, ieee types and arithmetic logic.

Well, I'm not quite up to that, but here's the procedure I use for
printf-debugging. Example usage:

if righteous
then        print("PASS " & test_name & " Final count = ", count);
else        print("Counter failure on loop ", death_loop);
            print("Failed while count = ", count);
end if;

-----------------------------------------------------------------
-- overloaded print() for strings, ints, vectors  
procedure print( constant printstr : in string)            
is begin  report printstr; end print;        
procedure print( constant printstr : in string;
                 constant printint : in integer)          
is begin  report printstr & integer'image(printint); end print;        
procedure print( constant printstr : in string;
                 constant printstd : in std_logic)        
is begin  report printstr & std_logic'image(printstd); end print;      
procedure print( constant printstr : in string;
                 constant printstv : in std_logic_vector)
is begin  report printstr & integer'image(to_integer(unsigned(printstv))); end
print;      
procedure print( constant printstr : in string;
                 constant printuns : in unsigned)        
is begin  report printstr & integer'image(to_integer(printuns)); end print;
procedure print( constant printstr : in string;
                 constant printsign :in signed)            
is begin  report printstr & integer'image(to_integer(printsign));end print;

------------------------------------------------------------------

--Mike Treseler

  vcard.vcf
< 1K Download


Sat, 28 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:

> Correct me if I'm wrong but waveform windows and list windows only work for
> signals.

There is no technical reason why they couldn't support
process variables also: they have a behavior over time,
just as signals do.

Actually, Synopsys VSS always supported this.
Modeltech's vsim did not for a long time: for us
this feature was so important that we only started
investing in that tool after it had this feature.

Regards, Jan

--
===================================================================
Jan Decaluwe              ===              Easics               ===
Design Manager            ===  VHDL-based ASIC design services  ===
Tel: +32-16-395 600          ===================================
Fax: +32-16-395 619      Interleuvenlaan 86, B-3001 Leuven, BELGIUM



Sun, 29 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:


>> Has anyone had success/problems with monitoring variables with
Active-VHDL?
>> (other than me:)

We ran into the same problem lately with ModelSim and Active-VHDL. In
Active-VHDL, you can click on the variable declaration in your code and
drag-and-drop it into your waveform window (AVHDL's support for drag and
drop is amazing :-).

Nick



Sun, 29 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:
>We ran into the same problem lately with ModelSim and Active-VHDL. In
>Active-VHDL, you can click on the variable declaration in your code and
>drag-and-drop it into your waveform window (AVHDL's support for drag and
>drop is amazing :-).

Do you mean signals?  I've been able to drag and drop them from the
Design Browser, but variables aren't listed in the browser.  I've been able
to
drag and drop variables from the editor to the watch window BUT when I try
to
check their value by double clicking on the value in the watch window I get
KERNEL: Error: Cannot find variable waves

I should clarify that the variables I am trying to display are within a
procedure
(not a process).

I think I will need to try some of the debugging techniques suggested in the
other
posts!

Steve



Mon, 30 Apr 2001 03:00:00 GMT  
 Why are Variables so hard to monitor?

Quote:

> >We ran into the same problem lately with ModelSim and Active-VHDL. In

> >Active-VHDL, you can click on the variable declaration in your code
> and
> >drag-and-drop it into your waveform window (AVHDL's support for drag
> and
> >drop is amazing :-).

> Do you mean signals?  I've been able to drag and drop them from the
> Design Browser, but variables aren't listed in the browser.  I've been
> able
> to
> drag and drop variables from the editor to the watch window BUT when I
> try
> to
> check their value by double clicking on the value in the watch window
> I get
> KERNEL: Error: Cannot find variable waves

> I should clarify that the variables I am trying to display are within
> a
> procedure
> (not a process).

> I think I will need to try some of the debugging techniques suggested
> in the
> other
> posts!

> Steve

   Variables can change sevral Times within a tick.
  the only tool that can handle variables is synopsys vhdldbx.
  they only can be handled if they ate declared in the process.


Fri, 04 May 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Why so hard to get started in Eiffel?

2. Why is Rexx hard to compile.

3. Why JPython for the hard stuff?

4. why is tree-shaking hard?

5. why why why oh why why baby

6. Need to find out how to use variable instead of hard coded

7. Variable monitoring widget for Tk

8. Why am I getting bind errors?

9. ERROR 48 - Why am I getting it?

10. why am i getting processor stack fault error?

11. Hard disk problems - Hard ones :))

12. Hard disk I/O the hard way

 

 
Powered by phpBB® Forum Software