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