« Prev | Next » HDL Debugging in Active-HDL Introduction The design verification process typically involves a lot of tedious work as well as a good understanding of the models behavior. However, since the VHDL and Verilog language guarantees that any model description is vendor-independent and exchangeable, the design verification efforts can have long lasting results. Because it is human nature to make an occasional mistake, you need to check the design for errors. Active-HDL provides several mechanisms for debugging VHDL and Verilog code: Syntax Checking - performed with the every Compile command. Code tracing - HDL code is executed either statement-by-statement or traced by processes, subprograms and procedures. Value verification - variable values are displayed in additional Watch and List windows. Syntax Checking Active-HDL provides you with an interactive VHDL and Verilog code debugger. After each execution of the Compile command an error list is displayed in the Console window. Each error is displayed with additional information: name of the source file internal error number line and column number location of the error in the code a short description of the error Double clicking on any of these errors takes you directly to the line of HDL code where the error has occurred. Furthermore, the line is underscored with red zigzag line and a red marker is placed to the left of the line. Pointing on a line with the cursor for a second, invokes the same short error description as reported in the Console window. Interactive Debugging The Compile command automatically checks the HDL source code for compliance with VHDL and Verilog LRM. By default, the compiler stops syntax checking after the 100th error, however, you can change that value in the Compiler tab of the Preferences window. Note: The Preferences window can be invoked from the Tools menu, selecting the Preferences option. The Preferences Window for VHDL Compiler The Preferences Window for Verilog Compiler The Preferences window allows customization of the debugging options as well. In the Debug tab window you can specify your preferences for code tracing. Document Type allows you to select the source document from HDL code or State machine. The checkbox Bring active source window to top invokes the source code window currently being debugged. Show component instances in specifies the way each component is viewed. They allow you to display a Separate view for each component or a Single view for all components. The Preferences Window for Debugger Active-HDL allows checking the State Machine generated HDL code for errors. In the same window you can select one of the two options: trace the original state machine trace HDL code generated from a state machine Code Tracing When the code syntax is error-free you can start verifying the models behavior. Active-HDL provides you with Waveform Editor, where all results are presented in the form of waveforms. You can quickly find any faulty and undesired design responses. To get more specific information on the Waveform Editor, please refer to the application note on Waveform Editor features. Active-HDL provides an interactive graphical environment for design development and verification. When necessary, you can trace the HDL source code statement-by-statement. There are four functions that allow you to trace the code: Trace into - executes a single HDL statement. If a subprogram call is encountered, the execution descends into the subprogram body. Trace over - executes a single VHDL or Verilog command. If a subprogram call is encountered, the statements contained within the subprogram body are executed in a single step. Trace out - executes as many HDL statements as required to complete the execution of a subprogram. If subprograms are nested, the command completes the execution of the innermost subprogram only. Trace over transition - executes as many HDL statements as required to perform a transition between states. To perform any of these commands, choose the appropriate options from the Simulation menu or click the Trace icons. The last transition option is available only while verifying state machines. State Machine Code Debugging The Trace over Transition option from the Simulation menu handles the State Machines. Active-HDL offers you a graphical editor for entering and editing of State Machines. Furthermore, the real-time State Machine editor allows you to interactively trace the behavior of the state machine: it allows you to determine which state is the current state, since the current state will be highlighted in yellow, like the example shown below. All Trace commands are active during the design debugging and so are the other tools described in this chapter. Therefore, you may trace any single statement in the HDL code and observe its influence on the model's behavior. The State Machine Editor Breakpoints Another useful feature of Active-HDL is its ability to insert breakpoints into HDL code. Breakpoints allow you to stop the verification process when some desired condition(s) occurred. All processes are suspended and signal values are displayed in the Watch window. The HDL Editor allows inserting breakpoints only in the lines where appropriate, for example: statements containing assignment expressions, etc. Simulation Breakpoint The Breakpoint Editor has three columns for Code breakpoints. The first column has a checkbox for enabling the breakpoint, the second has a path to the source file where the breakpoint is inserted and the third has a line number in the breakpoint's source file. The Breakpoint Editor allows manual toggling of the breakpoints. Moreover, there is also a dialog window where you can add signals that you want to trace. There are three columns displaying the Name of the signal, the Condition at which the simulation should stop, and the Value of the signal. In the Condition tab there are three options: Event - the simulation stops when the signal event occurs. Value - the simulation stops when the specified value is either generated for the signal, or the simulator forced it. Transaction - the simulation stops when the signal transaction occurs. You may quickly jump to the location of the breakpoint by clicking the Show code button in the Signal and Code breakpoint tabs. This is a very convenient method of locating breakpoints in situations where multi-file projects are verified. The Code Breakpoints Results Verification You can use additional tools during tracing the HDL model's code to help you to verify the design's overall responses. In addition, there may be some specific conditions that the model should be tested for; these could cause certain behavior of the model. Sometimes it is best to look for the specific signal values that can be displayed not only in the Waveform Editor but also in the following windows as well. List Window The List window displays all results in a tabulated form. The window is used only as a viewer for simulation results. Because of that you cannot define stimulators here. The contents of the window can be saved to a text file. Each signal is represented by a column with corresponding event times. The window can display signal values in two ways: For all simulation cycles executed for the specified time step. Only for the last simulation cycle within the specified time step. The List Window Watch Window To find the last value or current signal's value, you may use the Watch window. The Watch window displays values of selected signals (including ports) and variables. The Watch Window The window is divided into four columns that show: names types of the selected objects current value last value last event time All signals viewed in this window can be dragged and dropped here, from the Design Browser window. You can also drag a signal name from the HDL source code itself. Processes Window The Processes window displays a list of processes in the elaborated model along with their current status. This window is available only while the simulator is running. The Processes Window The processes are displayed in three columns that show the process label, hierarchical path and status of each process. Each concurrent statement modeling a sequential process is represented in the window. There are: process statements concurrent signals assignment statements concurrent assertion statements concurrent procedure call statements For processes without explicit labels, the compiler generates default labels that show the line number of the source file in which a process is located (e.g., line__25). In case of processes declared within generate statements, their labels are modified by a suffix showing the instance number. A process listed in the Process window can have one of the following status: Ready; indicates that the process is scheduled to be executed within the current simulation cycle. Wait; indicates that the process is suspended and waiting to resume. The Processes window can show either: All processes in the selected region of the elaborated design irrespective of their status in the current simulation cycle. Only active processes in the selected region of the elaborated design, that is those scheduled to be executed within the current simulation cycle. In addition, you can choose a region of the design whose processes you want to trace. Call Stack Window The Call Stack window is a debugging tool that displays a list of subprograms (procedures and functions) and variables being currently executed. The term process is used here to mean any concurrent statement modeling a sequential process in the elaborated model. Such statements are process statements, concurrent signals assignment statements, concurrent assertion statements, and concurrent procedure call statements (exactly the same as for the Processes window). For each subprogram, the window displays the following information: Formal parameters along with their actual values. Variables, constants and files declared locally in subprogram bodies along with their current values. If there is more than one process in the simulated design, you can use the Processes window to select the process whose subprograms you want to watch. The Call Stack window is available only while the simulator is running. The Call Stack Window Memory Viewer The Memory View window is a debugging tool that has been designed to display the contents of memories defined in an active design (e.g. objects of the two-dimensional array type). Values stored in a memory, their type, word length, memory depth, and the address range can be observed during the simulation. An object to display can be either a VHDL signal and variable or Verilog arrays of the reg or integer type. The Memory View window allows you to view objects as if they were memory cells. In the window, you can manually specify the address range, edit a value of memory cells and save the contents of the memory in a text file. The Memory Viewer window Advanced Dataflow The Advanced Dataflow is a tool that allows designers to explore the connectivity of an active design and analyze dataflow among instances, concurrent statements, signals, nets, and registers during simulation. The hierarchical, flat, or gray dataflow diagram displayed by the Advanced Dataflow Viewer may be especially helpful while tracing events propagating through the entire project and identifying those that may be potential sources of unexpected output values. The Advanced Dataflow Window X-Trace X values can be the source of unexpected outputs of the tested module. Active-HDL provides xtrace - a command-line utility that allows you to detect X or U values when they first appear, before they are propagated to the output ports. The xtrace command used with the -hold switch stops the simulation when an X or U value is assigned to any of monitored (xtraced) signals. A message about an unexpected value is printed to the Console window. A double click on the line with the message takes you directly to an assignment that resulted in the unknown value. Please refer to Locating X values with xtrace Active-HDL application note for more details. Conclusion Active-HDL has much to offer for both beginners and more advanced users. Some developers prefer to use commands invoked from menus and some find it easier to use shortcut keys. At the beginning you will probably use the menus. As you familiarize yourself with the program, you will probably use the shortcut keys, which is usually the fastest method to get the job done. As stated in this chapter, Active-HDL offers a number of options that will help you to effectively debug any errors in your design. Those tools are not limited to checking of the HDL code but they let you efficiently verify the behavior of your design as well. Active-HDL has a number of options that let you quickly trace the desired statements in HDL code, processes and procedures. There are also options for tracing signal behavior and for checking and saving simulation results in files. Moreover, Active-HDL allows you to stop simulation at any time when user defined conditions are met. You can insert the breakpoints in the HDL code to stop the simulation when the specified code line is entered, and since the Active-HDL environment is interactive, you can execute the debug functions while the simulation is in progress. Finally, all of the debugging tools that are described in this application note are all in the on-line mode (simulation in real-time), thus, debugging large designs using these tools may lead to an inefficient use of time. To eliminate such disadvantage, a debugging tool in the off-line mode called Post Simulation Debug is available in Active-HDL. The Post Simulation Debug is an advanced feature that allows users to observe the simulation results for debugging even after the simulation has finished, and thus, allows you to debug your code even repeatedly at any point of the simulation. For more detailed information on this, please refer to the application note on Post Simulation Debug. Previous article Next article
