RE: [vhdl-200x] Packages and Error Checking

From: Richard Wallace <wallacerim@aol.com>
Date: Thu Jan 09 2014 - 18:43:28 PST
Jim,
	Java has such a built-in stack dump that will lead to the
instantiated class.  I am not, nor will I even think of, advocating  Java
semantics for VHDL.  I'm thinking that you'll need more symbols stored by
the simulator/compiler to capture instantiation data and this is what Java
has to do for its RTE.
	Do not use assertions, these are just dressed-up printf() debugging
techniques.  Code becomes littered with these little bits of flotsam and
jetsam and they don't do any good if a true symbol-based stack dump is
unavailable.  A true entity based tracing mechanism is needed.

V/r,
Richard Wallace
UAV Network and Systems Architect
www.riversideresearch.org
(One of the originals of VHDL)

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Jim Lewis
Sent: Thursday, January 09, 2014 6:36 PM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] Packages and Error Checking

Hi,
As I work more on the OSVVM packages, I find myself adding checks that are
essentially debugging aids.  Without the checks, the error will be found,
but not anywhere that it gives any trace back to the procedure that actually
caused the issue.

What I am wondering is that if we need some syntax or other notation that
indicates the code is used for enhancing debugging and is not necessary in
production code that has been debugged.  The intent is that when the design
is optimized with certain flags set, the checks will be removed, but with
low levels of optimization the code will be kept.

The indication could be subprogram based, such as a function named
debug_check that simply returns the value it receives:
       if debug_check(A'length < Unique) then
         report "RandIntV: Unique > length of set of values" severity
failure ;
         iUnique := A'length ;
       end if ;

In addition, sometimes code of this nature can be avoided if we had
subprogram that caused a call stack dump or a call stack dump in the current
package - similar to what happens when a simulator encounters a "FATAL"
error.  Hence, the failure may be detected at a fairly low level, but the
stack dump will lead to the top level subprogram in the package that was
involved in the generation of the issue.

Anyone aware of another language that has this type of capability or
utilities.

Best Regards,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
VHDL Training Expert, SynthWorks
IEEE 1076 VHDL Working Group Chair
Open Source VHDL Verification Methodology (OSVVM), Chief Architect and
Co-founder

1-503-320-0782
Jim@SynthWorks.com
http://www.SynthWorks.com

VHDL Training on leading-edge, best coding practices for hardware design and
verification.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jan 9 18:43:53 2014

This archive was generated by hypermail 2.1.8 : Thu Jan 09 2014 - 18:44:15 PST