Date: Thu Jan 09 2014 - 15:44:24 PST
Jim, It sounds like you are describing assertions in software: <http://en.wikipedia.org/wiki/Assertion_%28software_development%29>. There is a huge literature on this. Some languages allow assertions to be hierarchical, and one can enable/disable various levels of checking as needed. A somewhat different and more programmer-level approach is to build in a trace facility. One standard way to do this is DTrace: <http://en.wikipedia.org/wiki/DTrace>. This also has a large literature. Joe Gwinn From: Jim Lewis <Jim@synthworks.com> To: "vhdl-200x@eda.org" <vhdl-200x@eda.org> Date: 01/09/2014 06:37 PM Subject: [vhdl-200x] Packages and Error Checking Sent by: owner-vhdl-200x@eda.org 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.
