The Story of “Debug”
It is the first step to improve your verification productivity
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” This is one of the best pieces of advice Albert Einstein has given us. Understanding the problem or the cause of the problem is the first step of any problem-solving. In the computer world, it starts with “debugging”.
The term “debugging” originated from an interesting incident in the 1940s when Admiral Grace Hopper, a US Navy scientist was working on a Mark II computer at Harvard University. Mark II used high-speed electromagnetic relays instead of the electro-mechanical counters used in the Mark I, making it much faster than its predecessor. One day the computer operation was disrupted, and when Grace’s team traced the cause of the problem, they found an actual bug (a moth) that got stuck in one of the relays. When the insect (bug) was removed, the computer returned to its normal operation – whereupon she remarked that they “de-bugged” the system. On September 9, 1947, this moth was taped to the computer’s logbook, with the note “first actual case of a bug being found” 😊
Fast forward to today, a recent Wilson Research Group study highlights where verification engineers are spending their time. They are involved in Test planning, Testbench development, Running simulation, and Debug. Out of all these tasks, debug is the most critical as it consumes more than 40% of their time.
Debug spans across all aspects of the semiconductor design and verification process, however of all the other classes, debugging a mixed-signal design is a tedious and time-consuming task. This is because debugging a mixed-signal design requires expertise from both the worlds – digital and analog.
For fast turnaround and to iron out preliminary bugs most verification engineers rely on higher abstraction in their verification methodology such as the use of real number model (RNM). This empowers the verification engineers to describe an analog block as a discrete floating-point model and enable it to simulate in a digital solver at near-digital simulation speeds. In a design, when an RNM block interacts with a standard logic block, signal conversion happens, and “real to logic” and “logic to real” boundary elements are inserted by the digital solver. The same is true in the case of a mixed-signal simulation when SPICE interacts with Logic or RNM blocks. The mixed-signal simulator inserts an “electrical to real” or “electrical to logic” boundary element. As the design hierarchy and complexity grow, the number of interactions increases, and it becomes cumbersome to debug these boundary conversions.
To learn more about mixed-signal debug methodologies, you can read our published article on semiengineering “Hug the Debug” and to gain insights on what Siemens EDA has to offer to improve your mixed-signal debug productivity, watch our webinar “When it’s do or die – choose Debug“. This webinar talks about Siemens EDA mixed-signal platform Symphony and Visualizer mixed-signal debug.
