Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Thinking forward
Andreas Veneris, Sean Safarpour
5/17/2012 12:23 PM EDT
Since its inception, the EDA workhorse of design and verification has been the simulator. Simulating designs has inherently played a central role in an engineer’s ability to develop and verify both simple and complex chips. Essentially, what the simulator allows one to do is to examine the circuit “forward in time” to understand how different scenarios may play out or intertwine. In this manner, one can recreate event by event all future interactions between different circuit elements, signals and modules to predict their behavior. It goes without saying that when engineers design, they think in a similar way that the simulator works. And, this means that they think by tracing events forward in time.
In contrast, once a failure occurs during verification, engineers tend to change their “forward” way of thinking. Currently, to debug a failure, they typically start with the given “bad” state or the failing signal and traverse “backward” in the design until they localize the source of the error. Using time-consuming manual RTL circuit and waveform viewers, engineers step back in time, event-by-event, by examining numerous signals through their drivers and by tracking a list of endless possible scenarios. In other words, with manual debugging GUIs and methodologies, they do not leverage a “forward” way of thinking. Forward thinking is a fact accustomed with the simulation phase, and, as we point out with this article, it is also one that comes naturally during the debugging task as well.
It may be the case that not many engineers have thought twice about this contrast between “forward” design and “backward” debug. And why would they? This contrast has been around for decades. Even in their daily lives, they face similar situations: They plan their days forward using calendars, set short- and long-term goals and work with deadlines. But when a problem occurs, such as misplacing a smart phone, they attempt to “back trace” their steps until they find the solution. “Did I have it at the gym, did I bring it at dinner, or did I use it during lunch?”
Several verification companies have looked at ways innovate automated debug and root cause analysis, and to develop technology and methodologies to tackle this manual verification challenge. One technology has emerged, offering a more natural way to move beyond debug by “debugging forward.”
The current state of debug
When a failure first occurs, engineers tend to look for the low-hanging fruit first by trying to guess at the source of the problem. For example, they may attempt to guess and concentrate on a few lines of recently modified code or their gut-feel tells them to focus on part of the code that is more complex. Finding the bug through this process can save debug time and it pays for the investment. But if this initial quick guess does not resolve correctly in finding the culprit, then a more traditional systematic debugging process begins.
This typically means dumping additional debug messages and value databases, loading waveform viewers, and starting a tedious “backward” traversal process. This process is often called path-tracing or back-tracing and it is one that engineers are much too familiar with. It entails looking up signal values in the waveform, jumping to the driving signals and statements in source code, and asking questions such as, “Is this signal or is this piece of code behaving correctly?”. These questions are repeated for different suspects under various scenarios. It is a process that becomes even more extensive and cumbersome when branches are encountered and the engineer must decide which branch to select to continue tracing with.
Evidently, during these steps, the “backward” way of thinking prevails in full effect as new questions arise to complicate further the debugging effort. “Where is this value coming from?” “What was the previous state?” “What is driving this signal?”
Consider an example where the output of a multiplexer (a Verilog case block in Figure 1) is suspected after back-tracing to be wrong. Here, the engineer must consider scenarios such as the control signal “mux_sel” is incorrectly picking from the wrong input or the value on input “mux_in1” is wrong. For each option, the corresponding driver must be found and the engineer must consider whether changing either or both signals can fix the observed failure. In other words, the engineer intuitively tries to use a forward direction of thinking while back-tracing to solve the problem. This process becomes even more extensive and complex as the user navigates back from driver to driver through a tree with dozens (if not hundreds) of branches.
Forward Debug
New automated software presents a way to solve the old debug problem by allowing users to debug in a “forward” manner similar to running simulation. And, here is how forward debug works.
The software performs automated root cause analysis of a failure by leveraging complex algorithms and mathematical models. The result is a list of all the possible ways that a given functional failure can be fixed by changing the RTL code. It finds all suspect signals, statements and other constructs that can undergo a functional change to correct the failure. Further, using the software, the user can view “suspects” and observe the paths of the bug to the failure points.
Additionally, for each suspect, the tool suggests fixes that show how a new value can propagate (that is, simulate) through the circuit, like falling dominos, to eventually rectify the buggy behavior. Figure 2 shows the suspect waveform where the fix value is in yellow and the remaining waveforms display the propagation of the fix value all the way to the failure point.
The software automatically performs “what-if analysis” on the entire circuit and presents the suspect locations and fixes to the user is another way of explaining how it works. Automation in this case reduces the manual back-trace effort by the engineer dramatically. As a result, the user can immediately apply a “forward” way of thinking, similar to the one used when designing. Instead of spending resources to manually back-trace the design and question about different paths and debugging scenarios, the user is faced with the information to pose forward-thinking questions. “Do I want to fix the problem here, since I now know that the correction propagates to these signals and it fixes the failure in that manner?” This makes debugging easier and faster.
Just like in simulation, for debugging, it also pays to think and act in a forward direction. With software, such as OnPoint from Vennsa, a forward way of thinking becomes another key tool as engineers move beyond debug.
About the authors
Dr. Sean Safarpour is chief technology officer and vice president of engineering of Vennsa Technologies, and has extensive industrial and academic experience in hardware and software research and development. Prior to co-founding Vennsa, Dr. Safarpour held various ASIC and FPGA design and verification positions. He received his Ph.D. from the University of Toronto.
Dr. Andreas Veneris, president and CEO of Vennsa Technologies, is a leading authority on circuit debugging and verification. As a professor at the University of Toronto, he has published more than 100 papers on debugging and delivered specialized in-house tools to many semiconductor companies. Previously, he was a visiting faculty at the University of Illinois at Urbana-Champaign, where he also obtained his Ph.D.
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
In contrast, once a failure occurs during verification, engineers tend to change their “forward” way of thinking. Currently, to debug a failure, they typically start with the given “bad” state or the failing signal and traverse “backward” in the design until they localize the source of the error. Using time-consuming manual RTL circuit and waveform viewers, engineers step back in time, event-by-event, by examining numerous signals through their drivers and by tracking a list of endless possible scenarios. In other words, with manual debugging GUIs and methodologies, they do not leverage a “forward” way of thinking. Forward thinking is a fact accustomed with the simulation phase, and, as we point out with this article, it is also one that comes naturally during the debugging task as well.
It may be the case that not many engineers have thought twice about this contrast between “forward” design and “backward” debug. And why would they? This contrast has been around for decades. Even in their daily lives, they face similar situations: They plan their days forward using calendars, set short- and long-term goals and work with deadlines. But when a problem occurs, such as misplacing a smart phone, they attempt to “back trace” their steps until they find the solution. “Did I have it at the gym, did I bring it at dinner, or did I use it during lunch?”
Several verification companies have looked at ways innovate automated debug and root cause analysis, and to develop technology and methodologies to tackle this manual verification challenge. One technology has emerged, offering a more natural way to move beyond debug by “debugging forward.”
The current state of debug
When a failure first occurs, engineers tend to look for the low-hanging fruit first by trying to guess at the source of the problem. For example, they may attempt to guess and concentrate on a few lines of recently modified code or their gut-feel tells them to focus on part of the code that is more complex. Finding the bug through this process can save debug time and it pays for the investment. But if this initial quick guess does not resolve correctly in finding the culprit, then a more traditional systematic debugging process begins.
This typically means dumping additional debug messages and value databases, loading waveform viewers, and starting a tedious “backward” traversal process. This process is often called path-tracing or back-tracing and it is one that engineers are much too familiar with. It entails looking up signal values in the waveform, jumping to the driving signals and statements in source code, and asking questions such as, “Is this signal or is this piece of code behaving correctly?”. These questions are repeated for different suspects under various scenarios. It is a process that becomes even more extensive and cumbersome when branches are encountered and the engineer must decide which branch to select to continue tracing with.
Evidently, during these steps, the “backward” way of thinking prevails in full effect as new questions arise to complicate further the debugging effort. “Where is this value coming from?” “What was the previous state?” “What is driving this signal?”
Consider an example where the output of a multiplexer (a Verilog case block in Figure 1) is suspected after back-tracing to be wrong. Here, the engineer must consider scenarios such as the control signal “mux_sel” is incorrectly picking from the wrong input or the value on input “mux_in1” is wrong. For each option, the corresponding driver must be found and the engineer must consider whether changing either or both signals can fix the observed failure. In other words, the engineer intuitively tries to use a forward direction of thinking while back-tracing to solve the problem. This process becomes even more extensive and complex as the user navigates back from driver to driver through a tree with dozens (if not hundreds) of branches.
Figure 1: Back-tracing when debugging a multiplexer module
To try to escape from this repetitive and tedious exercise, many engineers will periodically make guesses and directly jump back across modules to key signals. With these guesses, they attempt to do even more “forward” thinking with questions such as, “Will changing this key signal propagate and fix the issue?”. If the guesses are not successful, they revert back to the systematic back-trace debug process.Forward Debug
New automated software presents a way to solve the old debug problem by allowing users to debug in a “forward” manner similar to running simulation. And, here is how forward debug works.
The software performs automated root cause analysis of a failure by leveraging complex algorithms and mathematical models. The result is a list of all the possible ways that a given functional failure can be fixed by changing the RTL code. It finds all suspect signals, statements and other constructs that can undergo a functional change to correct the failure. Further, using the software, the user can view “suspects” and observe the paths of the bug to the failure points.
Additionally, for each suspect, the tool suggests fixes that show how a new value can propagate (that is, simulate) through the circuit, like falling dominos, to eventually rectify the buggy behavior. Figure 2 shows the suspect waveform where the fix value is in yellow and the remaining waveforms display the propagation of the fix value all the way to the failure point.
Figure 2: The waveforms show the suspect “inst_data” found by the tool and displays the fix value of “4e6” in yellow versus the simulated value of “4e7”. In the FIXES section of the waveform the propagation of the fix value “4e6” is shown through signals “instr_0”, “src1”, “dout”, “rf_wr_data” and finally to the assertion that will no longer be failing.
The software automatically performs “what-if analysis” on the entire circuit and presents the suspect locations and fixes to the user is another way of explaining how it works. Automation in this case reduces the manual back-trace effort by the engineer dramatically. As a result, the user can immediately apply a “forward” way of thinking, similar to the one used when designing. Instead of spending resources to manually back-trace the design and question about different paths and debugging scenarios, the user is faced with the information to pose forward-thinking questions. “Do I want to fix the problem here, since I now know that the correction propagates to these signals and it fixes the failure in that manner?” This makes debugging easier and faster.
Just like in simulation, for debugging, it also pays to think and act in a forward direction. With software, such as OnPoint from Vennsa, a forward way of thinking becomes another key tool as engineers move beyond debug.
About the authors
Dr. Sean Safarpour is chief technology officer and vice president of engineering of Vennsa Technologies, and has extensive industrial and academic experience in hardware and software research and development. Prior to co-founding Vennsa, Dr. Safarpour held various ASIC and FPGA design and verification positions. He received his Ph.D. from the University of Toronto.
Dr. Andreas Veneris, president and CEO of Vennsa Technologies, is a leading authority on circuit debugging and verification. As a professor at the University of Toronto, he has published more than 100 papers on debugging and delivered specialized in-house tools to many semiconductor companies. Previously, he was a visiting faculty at the University of Illinois at Urbana-Champaign, where he also obtained his Ph.D.
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
|
|
|
|
|
Navigate to related information