Observing signals (and variables?) in a process 
Author Message
 Observing signals (and variables?) in a process

Howdy.

  I would like to be able to observe the value of a signal inside a
process, when the signal is defined in the process and not available on
a port of the process.  Note that this is NOT a "global signal" (for
instance, using a signal defined in a package).

  The point is to be able to create a testbench that makes decisions
based on values of signals (or variables!) in an arbitrary process,
without requiring any special constraints on how the process is written
(global variables, etc.).  Ideally the signal or variable would be
identified by the hierarchical name inside the design.

  This sort of thing is possible on most modern VHDL simulators via the
C-language interface (or other proprietary interface), but doing so is
both non-standard and additional effort.  The VHDL-93 (1076-1993) LRM
describes the "path_name" and "instance_name" attributes (section 14.1,
"Predefined attributes", lines 380-598), which work fine for dumping the
hierarchical name of the signal via ASSERT statements.  However, there
does not appear to be any way to use this information to view the value
of a signal.

  Any suggestions?

  Thanks.

    Cheers,

    Tom McConnell
--

Intel, Corp. CH6-210  | http://www.*-*-*.com/ ~tmcconne
5000 W. Chandler Blvd.| The opinions expressed are my own. No one in
Chandler, AZ  85226   | their right mind would claim them.



Tue, 28 Mar 2000 03:00:00 GMT  
 Observing signals (and variables?) in a process

This is a multi-part message in MIME format.

--------------5B7A65946E21
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Quote:

> Howdy.

>   I would like to be able to observe the value of a signal inside a
> process, when the signal is defined in the process and not available on
> a port of the process.  Note that this is NOT a "global signal" (for
> instance, using a signal defined in a package).

>   The point is to be able to create a testbench that makes decisions
> based on values of signals (or variables!) in an arbitrary process,
> without requiring any special constraints on how the process is written
> (global variables, etc.).  Ideally the signal or variable would be
> identified by the hierarchical name inside the design.

>   This sort of thing is possible on most modern VHDL simulators via the
> C-language interface (or other proprietary interface), but doing so is
> both non-standard and additional effort.  The VHDL-93 (1076-1993) LRM
> describes the "path_name" and "instance_name" attributes (section 14.1,
> "Predefined attributes", lines 380-598), which work fine for dumping the
> hierarchical name of the signal via ASSERT statements.  However, there
> does not appear to be any way to use this information to view the value
> of a signal.

>   Any suggestions?

Well, first of all I have to admit that I developped stuff based on
C-interfaces to circumvent this problem.

But the more experienced I get, the more I believe that you should
avoid such an approach and that you should use VHDL techniques.

I'm nowadays thinking if you need such an 'internal' signal to
build decent testbenches, then you most probably will need also
that signal to build decent real life tests of your final product.
So, make this signal visible on the interface and have it connected
up to a pin or up to a readable register or the like ...

What's your opinion ?

Kind regards.

--------------5B7A65946E21

Content-Transfer-Encoding: 7bit

     \\\|///      ir. Jos De Laender
     ( 0 0 )      Alcatel - SSD (Switching Systems Division)
   oo0-(_)-0oo    ASIC design - VH14                
  _\   ' `   /_
  \ \ALCATEL/ /   F. Wellesplein 1, B-2018 Antwerp, Belgium
   \ \     / /                                

     \ \ / /                                                                
     o0 Y 0o      Alcatel Bell    : http://www.bel.alcatel.be
       \|/        Alcatel Telecom : http://www.alcatelecom.be
        *         Phone           : (32)(0) 3 240 74 61
                  Fax             : (32)(0) 3 240 99 47

--------------5B7A65946E21--



Fri, 31 Mar 2000 03:00:00 GMT  
 Observing signals (and variables?) in a process


Quote:
>Well, first of all I have to admit that I developped stuff based on
>C-interfaces to circumvent this problem.
>But the more experienced I get, the more I believe that you should
>avoid such an approach and that you should use VHDL techniques.
>I'm nowadays thinking if you need such an 'internal' signal to
>build decent testbenches, then you most probably will need also
>that signal to build decent real life tests of your final product.

I think that concept applies to test vectors used for verifying a
known good design does not have physical errors, but does not
necessarily apply to tests written while debugging the HDL,
or possibly even to so-called regression testing.

Steve



Fri, 31 Mar 2000 03:00:00 GMT  
 Observing signals (and variables?) in a process


Quote:
>I'm nowadays thinking if you need such an 'internal' signal to
>build decent testbenches, then you most probably will need also
>that signal to build decent real life tests of your final product.
>So, make this signal visible on the interface and have it connected
>up to a pin or up to a readable register or the like ...

A nice advantage of probing internal signals is potentially *earlier* error
detection, before the error makes its way to the boundary.  For simulation
this might make the difference between spotting the error or not spotting
the error.  In any event, designs are state machines and we should be able to
easily check their next-state functions along with their output functions.  

David Fura
Levetate Design Systems, Inc.



Fri, 31 Mar 2000 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. variable assignment in process or outside of process

2. Processing variable length/variable data files

3. Signal Processing Forth?

4. Signal Processing Toolset

5. file I/O and signal processing

6. Digital Signal Processing

7. Digital Signal Processing

8. DIGITAL SIGNAL PROCESSING

9. Signal and Image Processing in Functional languages

10. Error 1335 While Installing Signal processing Toolset 7.0 from DevSuite

11. Call Labview signal processing functions from CIN?

12. scheme for signal processing?

 

 
Powered by phpBB® Forum Software