Application Notes

Active-HDL
Copyright Aldec, Inc.
Application Notes
Table Of Contents
Starting Active-HDL ......................................................................................................................... 1 Design Entry Overview .................................................................................................................. 15 Design Management Overview ..................................................................................................... 27 Handling Libraries in VHDL, Verilog, and EDIF............................................................................. 37 Simulator Overview........................................................................................................................ 45 BASIC Scripting Capabilities ......................................................................................................... 54 Tcl/Tk Scripting .............................................................................................................................. 61 Creating FPGA and CPLD Designs............................................................................................... 71 How to Simulate Designs .............................................................................................................. 77 Using Stimulators........................................................................................................................... 85 VHDL Testbench ........................................................................................................................... 91 Glitches and Delta Cycle Handling ................................................................................................ 99 VHDL Debugging......................................................................................................................... 107 Building and Debugging Handel-C Projects ................................................................................ 115 Co-simulation of Handel-C Projects in Active-HDL ..................................................................... 125 Using Celoxica Flowchart ............................................................................................................ 133 Using TestBencher Pro with Active-HDL ............................................................................. 141 Building PLI Applications ............................................................................................................. 149 Building VHPI Applications .......................................................................................................... 157 Debugging C/C++ Applications ................................................................................................... 167 Using Design Profiler ................................................................................................................... 175 Using Toggle Coverage............................................................................................................... 179 Co-simulating VHDL and System-C ............................................................................................ 183 Co-simulating Verilog and System-C........................................................................................... 187 Index ............................................................................................................................................ 191
Starting Active-HDL
Installation
The installation of the Active-HDL system is invoked automatically by running the setup.exe program from the CD-ROM drive after you put the installation CD. The Install Shield Wizard that assists you in the installation process will ask you to enter registration and configuration data including your name, the company name and the destination folder that will store the Active-HDL components. During the installation process, all Active-HDL files are copied into their destination folders. Most files are copied into the default Active-HDL folders. A number of files are copied into the WINNT\SYSTEM32 subfolder (Windows NT/2000/XP). Installation steps: 1. Launch the setup.exe file from the installation CD. This will invoke the Installation Wizard.
Installation Wizard 2. In this window, you are prompted with the license agreement text. After accepting by clicking the Accept button you will see the next dialog.
License agreement window.
Application Notes
3. Enter user personal data to work with the Active-HDL software.
Entering personal data After entering all required information, click the Next button. 4. You can install several editions of Active-HDL. In the Setup Type dialog, you can choose the following options: Vendor-Independent Edition This version allows installing Verilog, VHDL, both types of libraries. Altera/XilinxEdition The vendor-specific editions allow you to install only Verilog or VHDL libraries.
Selection of the Active-HDL edition After you have selected the edition of Active-HDL, click the Next button.
Starting Active-HDL 5. When you advance to the next window, you will be able to select which program components (vendor libraries) will be installed.
Selecting vendor libraries for installation The components not installed during the first installation cannot be added later and they will require a reinstallation procedure. Click the Next button when you have selected the required files. 6. Specify the installation folder and the folder for user-created designs.
Specifying the folders for user designs and the installation of Active-HDL By default, the software is installed in the C:\Program Files\Aldec\Active-HDL 6.2 folder and the designs are stored in the C:\My_Designs folder on the disk. To change the destination folders, click the Browse buttons. 7. In the next step specify the license environment for Active-HDL. During the installation procedure of Active-HDL 6.2 you can select the license environment that will be used to protect the program. The license environment settings should be related to the type of the license you have purchased. The following settings are available in the Choose License Environment window:
Application Notes
Specify the license environment for Active-HDL Evaluation license This option allows you to use Active-HDL 6.2 in evaluation mode for 20 days without any additional license. The evaluation version features the full functionality of a registered copy with some limitations. Hardware keylock/dongle (Parallel port) This option allows you to use a keylock-protected version of Active-HDL 6.2 based on the license stored in the device attached to the parallel port of your computer. The type of the license requires the Sentinel drivers to be installed on your computer. Hardware keylock/dongle (USB port) This option is a new type of the license supported by Active-HDL. It allows you to use a keylock-protected version of Active-HDL 6.2 based on the license stored in the device attached to the USB port of your computer. The type of the license requires the Sentinel USB drivers to be installed on your computer. Before you choose this type of Active-HDL licensing make sure your workstation supports the USB standard. The installation program will copy all required drivers to your computer. Additionally, make sure that during the installation the USB keylock device is not attached to the USB port of your computer. Network floating license This option allows you to use a version of Active-HDL that is protected by the network license manager. During the installation procedure the ACTIVE62_LICENSE_FILE variable is set. This variable should point to the location of the License.dat file or the license server.
Starting Active-HDL 8. In the final step of the installation, you can create file associations for the Active-HDL environment.
Selecting file extensions for Active-HDL Click the Next button, the setup program is ready to start copying files. The dialog displays information about the selected components for installation and their target folders. Start installation by clicking the Install button. 9. You can register your software or finish the installation by pressing the Finish button.
Finishing the installation
Evaluation Version
When you install Active-HDL for the first time on your computer, it will work in evaluation mode for 20 days without any additional license files or keylocks. The evaluation version provides the full functionality of a registered copy with the following limitations: Printing is disabled. The maximum simulation time is 10 us.
Application Notes The maximum amount of memory allocated per VHDL, Verilog or mixed VHDL-Verilog design is 5MB. This limitation decreases to 2 MB for any designs employing EDIF-based design units. Block diagrams containing more than 15 fubs and/or symbols cannot be saved.
Single User
If you purchased the Active-HDL software for a single user, then you have been supplied with a hardware keylock or a license file. The keylock is a device that plugs into the parallel port of the computer. While the Active-HDL software is loaded, the parallel port is automatically tested to verify whether you have a valid keylock to run the program. In case of a license file, the FlexLM license manager checks whether a valid license LICENSE.DAT file is stored in the DAT subfolder of the Active-HDL installation folder.
Network Version
Active-HDL 6.2 supports the new licensing capability that enables user to have different product configurations on one Floating License. With the new licensing the separate users can access the options available for the different product configurations. The change in licensing forces the existing users of previous versions of Active-HDL to update their license before running the new release. If a user has purchased Active-HDL 6.2 with network licensing containing several product configurations, he/she will be able to switch among these configurations each time the program starts. If a user has purchased the network license with only one product enabled in a license file, he/she has the possibility to use only one given configuration. In this case the License configuration window can be omitted during the Active-HDL start-up. To do so, the Do not display this dialog again box must be checked. All products enabled in a license file can be seen after pressing the License information button.
Uninstall
To uninstall Active-HDL, click the Start button in the Windows task bar and select Settings | Control Panel. In the Control Panel window, click the Add/Remove Programs icon.
NOTE: You should not uninstall Active-HDL manually.
Modification of previous installs

With Active-HDL already installed in your computer you cannot add previously omitted components at any time. To do this, you need to run the installation software again.
NOTE: User projects are not removed during uninstall and will be visible in a new version of Active-HDL.
Starting Active-HDL
Hardware and Software Requirements

Active-HDL 6.2 requires: A Pentium PC or higher/compatible 128 MB physical memory (256 MB recommended)
Microsoft Windows NT 4.0 with Service Pack 6 , Windows 2000 with Service Pack 3 (recommended), or Windows XP with Service Pack 1 (recommended) Microsoft Internet Explorer version 4.0 or higher (see Notes) Hard disk drive with at least: Vendor-Independent Edition and Synplicity Edition 360MB of free space for minimal installation (2GB for full installation including all available libraries). Altera Edition 460MB for VHDL or 390MB of free space for Verilog installation. Xilinx Edition 490MB for VHDL or 440MB of free space for Verilog minimal installation 940MB for full VHDL or 890MB of free space for full Verilog installation (including all schematic libraries).
NOTES: The hard disk drive requirements are approximate and depend on both your operating system and chosen file system. The amount of available physical memory limits the maximum size of the design that can be simulated in Active-HDL. For full functionality, Active-HDL 6.2 requires that the Microsoft Internet Explorer version 4.0 or higher is installed on your system. If not, the following system components will not be available: Dataflow window Query window in Block Diagram Editor On-line documentation
If you have a different Internet browser (other than Internet Explorer) installed on your system, you can continue to use it without any problems. Internet Explorer can be installed as a non-default browser and be used only by Active-HDL.
Application Notes
Folder Structure
Active-HDL 6.2 is the default root folder for all Active-HDL 6.2 files. The Active-HDL 6.2 folder structure is shown below.
The structure of the Active-HDL folder The Active-HDL installation folder includes: Active - Active-CAD executables and auxiliary files necessary to import Active-CAD designs to Active-HDL environment Bin - Active-HDL executables, Profiler, Code Coverage, debugger, and auxiliary files Books - Help and documentation files Dat - License files Denali - Denali interface files Drivers - Sentinel drivers for the keylock Etc - Debussy interface files Evita - Evita interactive tutorial files Flows - Design Flowchart configuration files IP CORE - IP CORE Generator files and documentation License - Network licensing software and keylock utilities MATLAB - MATLAB interface files MinGW - Gcc compiler and gdb debugger files NetSetup - Active-HDL network installation files Perl - Perl executable and auxiliary files Pli - Verilog PLI auxiliary files Script - Sources of scripts used in Active-HDL SWIFT_LMTV - Files required to build the swift_lmtv.dll library that allows using the LMTV interface. Synopsys - Interface to Synopsys FlexModels SystemC-2.0.1 - SystemC Class Library files (ver. 2.0.1) Tcl - Tcls scripts Template - Language Assistant files Training - Sample training designs and PowerPoint format presentation files Vlib - VHDL, Verilog, and vendor-specific libraries
Starting Active-HDL
Files Installed in Windows Directories

The following files are copied to the \SYSTEM32 subfolder (Windows NT/2000/XP): Atl70.dll Mfc70.dll Mfc30.dll Mfcd30.dll Mfcn30.dll Mfco30.dll Mfcoleui.dll Mfcuia32.dll Msvcr70.dll Msvcp70.dll Msvcp50.dll Saxbasic.hlp Sbpro32.ocx Stlport_vc745.dll Ww_cu232.dll Ww_mc232.dll Ww_0a232.dll
Active-HDL Components
All Active-HDL components are embedded into a unified graphical environment referred to as a framework. The framework provides workspace and is a communication environment for all system components. Except for the simulation kernel, each Active-HDL tool is implemented in a separate window. The following is a brief description of Active-HDL components: Console The Console window is an interactive input-output text device that: Provides entry for Active-HDL commands. Outputs messages generated by Active-HDL tools.
Design Browser The Design Browser window displays the current design contents, including: Resource files attached to the design. The contents of the design default working library. The structure of the design unit selected for simulation. Signals and variables declared within a selected region of the current design.
HDL Editor The HDL Editor is a text editor designed for HDL source files. It displays specific syntax categories in different colors. The editor is tightly integrated with the simulator to enable easy source code debugging. Language Assistant The Language Assistant is an auxiliary tool that provides a number of VHDL/Verilog templates modeling typical logic primitives and functional blocks. It is integrated with the HDL Editor so that you can automatically insert the desired templates into edited source files. The Language Assistant also allows you to define your own templates. State Machine Editor
Application Notes The State Machine Editor is a graphical tool used to created and edit state machine diagrams. The editor automatically implements translation of graphically designed diagrams into VHDL/Verilog code. Block Diagram Editor The Block Diagram Editor is a graphical entry tool for creating and editing top-level schematic files. This tool automatically generates EDIF and VHDL/Verilog code. Waveform Editor The Waveform Editor displays the results of a simulation run as signal waveforms. It allows you to graphically edit waveforms so as to create desired test vectors. List The List window displays the results of a simulation run in a tabulated text format. It allows you to trace simulation results with delta-cycle accuracy. Watch The Watch window displays the current values of selected signals and variables during simulation. Processes The Processes window displays the current status of concurrent processes in the elaborated design during simulation. Call Stack The Call Stack window is a debugging tool that displays a list of subprograms (procedures and functions) being executed in the currently executed process. Dataflow The Dataflow window is a tool providing a graphical view of signals flowing in and out of processes during simulation. Library Manager The Library Manager is designed to manage VHDL/Verilog libraries and their contents. Workspace/Design Explorer The Workspace/Design Explorer facilitates the management of Active-HDL designs. It is not necessary to remember the physical locations of design files. Design Flow Manager The Design Flow Manager is a tool that allows you to automate processes of simulation, synthesis, and implementation by using third-party EDA tools. Memory View The Memory View window is a debugging tool that has been designed to display the contents of memories defined in a design (e.g. objects of the two-dimensional array type). Server Farm Server Farm is an advanced and independent tool working on the local network that allows users to schedule tasks and then execute them automatically on the selected computers available on the network. Code Coverage Code Coverage is a program that allows you to test testbenches and determine how your source code is executed. Source Revision Control Active-HDL provides a powerful enhancement that allows you to communicate with external professional Source Revision Control systems. The built-in interface allows operating on previous versions of source files directly from the Active-HDL environment.
10
Starting Active-HDL
Design Files
During the design development, a number of files are created in the design folder. They are workspace and design configuration files, VHDL, Verilog, or EDIF source files, waveform files, script files, log files, library files, etc. The list of files used in Active-HDL designs along with their extensions is available in Release Notes.
Workspace and Design Structure

Every workspace and design is stored in a separate folder called the workspace/ and design folder, respectively. Both the workspace/design folder and the workspace/design have the same name. The workspace folder ($wsp) contains the workspace description file (AWS), the $wsp\library.cfg file that stores information on global libraries visible to every Active-HDL design and working libraries of all designs attached to the current workspace. Each design folder contains the SRC, LOG, and COMPILE subfolders as well as the design description file (ADF) which name is the same as the name of the design. The SRC subfolder may contain VHDL, Verilog, EDIF source files, block or state diagram files, macros and other source files. The COMPILE subfolder contains, among others, the generated from block or state diagrams VHDL or Verilog source codes. The LOG subfolder stores log files created while evaluating s design. The workspace/design configuration and status are described in the following files: AWS, ADF, CFG - workspace/design description and configuration files, respectively. Contain information on a workspace, a design currently set as active and design's structure: source files and libraries that belong to individual designs, compilation status, attached libraries, which files are open, what is the cursor position in each file, what bookmarks have been toggled, which windows are undocked, etc. WSW, WSP - files containing additional workspace/design data, e.g. on opened toolboxes, value of the simulation step set for each design. They can be restored even if they are deleted or corrupted.
NOTE: Since the workspace file describes the current design status, it may also contain such additional information as instability of the design resulting from an error. In such a case, the design may fail to open because of the unstable status written to the workspace file. If so, delete the corrupted workspace file to open the design with the default workspace settings.
Active-HDL Configuration Settings

Active-HDL configuration settings apply to both the current design (local settings) and the entire system (global settings). Local settings are stored in the workspace and design files stored in the design and workspace folders, respectively. Global settings include the user interface settings that are not the design related settings, e.g. the Console window state (docked or undocked). Global settings are stored in the avhdl.xml file (\Bin).
11
Application Notes
Active-HDL Libraries
Active-HDL libraries include system libraries and workspace/design libraries. System libraries are shipped with the Active-HDL software and are stored in the \VLIB subfolder. They have the readonly attribute set by default. Workspace and design libraries are created for particular designs and stored in design folders. The library structure is common for both design and system libraries. Each library consists of two files: LIB - the library index file MGF - the library main file, containing data used by the Active-HDL's compiler and code used by the Active-HDL simulator.
There are also two library configuration files - LIBRARY.CFG. The first one (mentioned above) is stored in the \VLIB subfolder and the second file is created along with a workspace and it stores information on workspace global libraries, that is, the libraries treated as global until the workspace is loaded. System libraries, stored in the \VLIB subfolder are pre-compiled standard libraries containing standard packages and primitives.
Built-in Standard Packages

Built-in packages contain subprograms whose code is embedded directly into the simulation kernel rather than generated by the VHDL or Verilog compiler. The code is optimized to accelerate the execution of such subprograms. The following is a list of packages for which the Active-HDL simulation kernel provides the built-in acceleration: Standard Libraries ALDEC STD VL Packages/Description Aldec Library with procedures for calling FSDB tasks from VHDL STANDARD TEXTIO Standard Verilog Library VITAL_MEMORY VITAL2000 VITAL_PRIMITIVES VITAL_TIMING STD_LOGIC_1164 VITAL_TIMING (VITAL 2000)* VITAL_PRIMITIVES (VITAL'95) VITAL_MEMORY* IEEE NUMERIC_BIT NUMERIC_STD STD_LOGIC_ARITH (also available in the SYNOPSYS library) STD_LOGIC_SIGNED (also available in the SYNOPSYS library) STD_LOGIC_UNSIGNED (also available in the SYNOPSYS library) * Active-HDL provides the IEEE library that includes the packages specified by Standard VITAL ASIC Modeling Specification, version 95 (IEEE Std 1076.4-1995) and 2000 (IEEE Std 1076.4-
12
Starting Active-HDL 2000). After the installation, the IEEE library containing packages coming from IEEE Std 1076.42000 is mapped by default. To use the IEEE library containing packages coming from IEEE Std 1076.4-1995: 1. Choose the Execute macro option from the Tools menu. 2. In the Execute macro window, go to the $ALDEC\Vlib\vital95\src directory and point to the remap_ieee.do macro. 3. Click the Open button. As a result of the macro execution, the IEEE library containing packages specified in IEEE Std 1076.4-1995 is mapped. To re-map the library, repeat step #2 selecting the remap_ieee.do macro stored in the $ALDEC\Vlib\ieee\src directory.
NOTE: The pre-compiled vendor libraries delivered with Active-HDL 6.2 require the IEEE library containing packages coming from IEEE Std 1076.4-2000. After the IEEE library is re-mapped, you will need to re-compile the vendor libraries.
On-line Documentation
Active-HDL provides the updated on-line documentation in the Compiled HTML (*.chm) format. Microsoft Internet Explorer 4.0 or higher is required to view the documentation in this format (it does not have to be set as the default Internet browser on your system). To open the on-line documentation, choose On-line Documentation from the Help menu. You can also load it by double-clicking the Umbrella.chm file stored in the \Books subfolder. The following on-line documentation files (\Books\*.chm) are shipped with Active-HDL: Active-HDL Main Help Page (Umbrella.chm) Active-HDL Help Topics (Avhdl.chm) Release Notes (Relnotes.chm) VHDL Language Reference Guide (Refguide.chm) Verilog Language Reference Guide (Vlogref.chm) VSimSA Standalone Simulation Environment Manual (Vsimsa.chm) HDL Entry and Simulation Tutorial (Tutavhdl.chm) PLI Reference Guide (PLIRef.chm) VHPI Reference Guide (VHPIRef.chm) Handel-C Reference Manual (HandelC.chm) Mixed Mode Entry and Simulation Tutorial (Tutbde.chm) State Machine Entry and Debugging Tutorial (Tutfsm.chm) VHDL Testbench Tutorial (Tuttbch.chm) VHDL Entry and Simulation Tutorial (Tutvhdl.chm) Verilog Entry and Simulation Tutorial (Tutvlog.chm) Mixed VHDL-Verilog Tutorial (Tutmixed.chm) Code Coverage Tutorial (TutCC.chm) VHDL Configuration Tutorial (Tutconf.chm) Post Simulation Debug Tutorial (TutPSD.chm) Server Farm Installation Tutorial (Tutsfadm.chm) 13
Application Notes Active-HDL Application Notes (Appnotes.chm) Using new features of Active-HDL macro commands and scripts (M42v5.chm) STD_LOGIC_1164 IEEE Package Reference (Stdlogic.chm) STD_LOGIC_ARITH IEEE Package Reference (Stdarith.chm) STANDARD Package Reference (Standard.chm) TEXTIO Package Reference (Textio.chm) Sax Basic Language Reference Guide (Saxbasic.hlp, in the Windows' System or System32 subfolder) Tcl/Tk Reference Manual (Tcl80.hlp) License Utility Help (Licutil.hlp)
Unless specified otherwise, all documentation files reside in the \Book subfolder of the ActiveHDL installation folder. In addition, Active-HDL provides an Enhanced VHDL or Verilog Tutorial (EVITA).
NOTE: The updated Active-HDL On-line Documentation is not limited and provides the help system for all features available in the full version of Active-HDL (Expert Edition (EE)). If you have a limited version of Active-HDL (Standard Edition (SE) or Plus Edition (PE)), you are still able to get the information on all available features. Contact Aldec for more information on license updates and new Active-HDL features.
14
Design Entry Overview

Introduction
Active-HDL is a new generation VHDL, Verilog, EDIF simulator. Its context graphical user interface is easy to use and makes your work easy in all stages of design development, starting from a hardware description, through synthesis, implementation, and debugging to design simulation. The HDL design entry process is supported by the following tools: HDL Editor - non-formatting text editor that includes a Language Assistant with a set of VHDL language templates. State Diagram Editor - a tool for creating FSM diagrams, which can be automatically converted into the corresponding HDL code. Block Diagram Editor - is a new graphical design entry tool. It allows you to create hierarchical block diagrams as an alternative to writing HDL code directly.
HDL Editor
The HDL Editor is a tool for creating HDL codes, testbenches, macros, scripts, and other text files. Active-HDL offers you several automated tools for a VHDL/Verilog code creation such as New Source File Wizard.
The HDL Editor
15
Application Notes
New Source File Wizard

Active-HDL allows you to create VHDL and Verilog files by selecting the Add New File command from the Design Browser window. The window that appears will give you a choice of commands. Block Diagram State Diagram VHDL Source Code Verilog Source Code Add Existing File
The Add New File Window. You can also choose from the following list of wizards: Block Diagram Wizard State Diagram Wizard VHDL Source Code Wizard Verilog Source Code Wizard
The Add New File Window - Wizards The Wizards facilitate design entry by introducing several steps. Each step requires some specific information about the file that is being created. STEP1: Specify whether the created code is to be added to the current project. STEP2: Choose the language that will be generated from a block or state diagram (only for BDE or FSM files). STEP 3: Enter the file name, entity and architecture or module name. The file names fields are mandatory. STEP3: Provide information about unit's ports.
16
The New Source File Wizard.
Language Assistant
The Language Assistant aides in speeding up HDL source code and script development. It provides a number of templates with prepared segments of code. There are several groups of templates: Code Auto Complete templates of HDL keywords or the whole constructs are inserted after typing the first initial letters and pressing the Space key. Language templates with basic language constructs. Simulation templates with sample processes useful while creating Testbenches, such as clocking signals, file accessing, etc. Synthesis templates with synthesis-oriented basic functional blocks, such as multiplexors, flip-flops, counters, etc. Tutorial with four templates that include counter, decoder, testbench, and sample toplevel specification. User templates where the user-defined templates are stored.
The Language Assistant Window. You can insert a selected template into a document being edited in the active HDL Editor window by dragging its name into the HDL Editor window. You may need to slightly edit the code to adapt it to your specific needs. Another method of inserting templates is to right-click the template label and select the Use command from context menu. The template will be inserted into the HDL Editor at the cursor position therefore you need to remember to place the cursor at insertion position. You can click the icon on the Language Assistant toolbar to insert the template.
17
Application Notes
Inserting the template The left panel of the Language Assistant window displays a hierarchical list of templates. The list is displayed in a tree-like form. Templates can be grouped into folders, added or deleted by users. A shortcut menu is available in the left panel. Its commands options duplicate the functions of the buttons. The right panel allows you to preview the contents of the currently selected template. You can assign a read-only attribute to templates to prevent accidental modification.
Color Preferences
The HDL Editor allows you to distinguish keywords, comments and constants from the rest of the text by displaying each item in a different color. The color selected for each keyword definition, as well as font type, may be specified in the Preferences | Environment | Appearance window. The color-coded file is much easier to follow. This feature is particularly useful for those users who are not strong in the HDL language. The HDL Editor checks the code syntax interactively since each keyword changes its color when correctly typed.
The Preferences Window. The syntax of the HDL file is checked every time the Compile command is executed. The HDL Editor will prompt you if any error occurred in the file. All error messages are logged into a file and displayed in a Compile window simultaneously. Additional code formatting features of HDL Editor improve the code readability. The icons for these actions are located in the left hand part of the window: - allows the selected text (code) indentation, - removes the indentation from the selected text, - converts the selected text into HDL comments,
18
- uncomments the selected text, - generates the structure for the selected text, which in result can be expanded or collapsed for improving the code readability. Thus created structure is displayed with the color background, - removes the structure generation from all groups, - generates the structure for the entire text along with automatic group partition. Such groups as VHDL entity port declaration, or IF .. THEN constructs are automatically collapsed. Particular groups are displayed with different colors, - automatically formats the selected code regarding the indentation, - adds the link (in a form of a comment to allow compilation) to a file located on the disk or on the Internet. By adding the link to the Internet page containing the detailed model specification you have direct access to the required information. (For example information on person using the project), - places the named bookmark in the code for better code navigation with the button.
Placing common bookmarks and navigating between them is facilitated by the icons located in the upper part of the editor window: These icons allow you to place a bookmark, jump to the next one, jump to the previous one and to remove a bookmark, respectively. Similar to color-coding the HDL keywords, you can define your own colors for the generated structure groups.
HDL Editor containing structures. Active-HDL speeds up writing the HDL code facilitating the completion of the following items: Reserved words - you can auto-complete only keywords after typing a few initial letters and pressing the Space or right arrow key. The keyword will be automatically expanded. The whole HDL constructs - you can auto-complete the whole VHDL or Verilog construct after typing a few initial letters and pressing the Space key. The template will be automatically expanded.
The following picture shows the code for the CASE template.
19
Application Notes
Code Auto Complete
State Machine Editor

The Finite State Machine Editor allows users a simple and easy graphical design entry. Since state designs can be easily retargeted to any devices, the state editors are becoming very popular with designers who value technological independence.
The State Machine Editor The State Machine Editor allows a graphical design entry in the form of state machines. In short, a finite state machine (FSM) represents behavior and functionality of a process in a limited number of "states". An FSM design contains the following attributes: A list of states A list of commands that can be accepted in each state A list of actions to perform for each command Actions can be of the following kind: send a command to another component (asynchronously and synchronously) execute a piece of code (user routine) set the state of the FSM design
A list of conditions for each state that cause the listed actions. Conditions remain active in the associated state and are reevaluated whenever a component changes its state, starts, or stops.
20
New Source File Wizard

Beginners should choose the New Source File Wizard to create a template of a state machine. The Wizard helps in a design creation process. When using the Wizard you will supply the same type of information as you would to the HDL code creator. The difference between a file created by the Wizard and an empty state machine file created by invoking the Add New File command, is that signal names and declared ports are automatically inserted into the Wizard's generated file. However, those names must be manually entered when using the Add New File command.
State Machine Toolbars

You can create any state machine in the State Machine Editor. By clicking on the corresponding icon in the State Machine toolbar, you can place any of the following items on the state machine diagram: standard and hierarchical state transition entry action state action exit action transition action machine or diagram action signal or variable junction input port output port bi-directional port hierarchy entry and exit link constant, generic, or parameter diagram or machine declaration reset or initial state text and graphical elements
The State Machine Toolbars. The State Machine Editor provides free editing. You can adjust the shape of a state circle or a transition arrow by dragging them in the desired direction. If an item cannot be placed in a certain area, the editor will not allow you to leave it there. For example, you cannot place a new diagram declaration in a state machine area. To change the machine properties, right-click and select the Properties option from the context menu. You can choose the clock for the state machine and specify if the machine is asynchronous or synchronous or it should work on a rising or falling edge. There are options controlling the decoding of the state machine, default states, reset conditions, and the machine behavior when conditions are not met.
21
Application Notes
The Machine Properties Window. The most important feature of the State Machine Editor is its ability to generate HDL code for the state machine diagram. You can perform this by selecting the Generate HDL Code option from the FSM menu or by clicking the Generate HDL code icon on the FSM toolbar. You can view the generated code by selecting the View HDL Code option from the FSM menu. Moreover, you may add a library clause when necessary. For example, when performing mathematical operations you can add the following library clause (VHDL): use IEEE.std_logic_arith.all library clause.
Block Diagram Editor

The Block Diagram Editor is a graphical design entry tool. It allows you to create hierarchical block diagrams as an alternative to writing a HDL code directly. The editor supports automatic generation of HDL from the diagram along with the advanced design rule checking (DRC). It allows you to mix all design description methods (pure HDL code, state diagrams and block diagrams).
Block Diagram Editor Window Similar to typical schematic based tools, the Block Diagram Editor lets you place, rotate and arrange the I/O ports, symbols, wires, buses, etc., The toolbar, with basic action buttons, is located in the upper part of the window. - switches to the editing mode for arranging the objects, etc.
22
- creates an empty macro symbol and places it in the schematic. - buttons for drawing wires and buses and naming them respectively. These buttons allow you to create the connections between the components.
- buttons for creating the I/O pads of the following type: input, output, bidirectional, and buffer respectively. Used for terminating wires and buses.
- buttons used for entering additional instructions or declarations. - symbols placed in the schematic representing VCC and Ground. - buttons for global signals and buses declaration. - opens the Symbols Toolbox containing available macros. Each VHDL entity or Verilog module from a library has automatically generated symbol here.
Symbols Toolbox window. You can place the symbol in the schematic by dragging it over the editor window and dropping in the desired location.
- buttons for placing additional elements such as text, drawings, and graphic files. You can edit the symbol placed in the schematic by selecting the desired symbol and choosing the Push command from the context menu.
23
Application Notes
Switching between symbol and its code. As you can see in the previous picture, by right-clicking the selected symbol, you have access to several different commands. You can, for example rotate or mirror the symbol, zoom it, etc. As mentioned before, each VHDL entity (Verilog module) description is represented by the automatically created symbol which can be placed in the schematic. To create an empty symbol in the schematic and generate its code later, you can draw a fub (Diagram | Fub (F) or the Fub icon) and choose the already mentioned Push command. You can then select between several different architecture description methods: Hierarchical schematic sheet using the Block Diagram Editor State Diagram using the State Machine Editor VHDL code using the HDL Editor Verilog code using the HDL Editor EDIF netlist using the HDL Editor
Defining the symbol architecture
24
Active-CAD Schematics
Active-HDL can import Active-CAD designs into the Active-HDL environment. Active-CAD schematics are converted to Active-HDL block diagrams. Multi-sheet schematics are converted to multiple-page block diagrams. Diagrams resulting from the conversion are set up for EDIF simulation, which means the Block Diagram Editor generates EDIF netlist from them instead of VHDL or Verilog. Hence, they benefit from the fast EDIF compilation in the Active-HDL environment.
Conclusion
HDL files guarantee that your code is portable and exchangeable between HDL editors. Having your projects written in the HDL makes you independent from vendor-specific layout tools. On the other hand, schematic files are generally stored in vendor-specific formats and cannot be applied to parts from other vendors. HDL files are much more flexible when the design you develop is described behaviorally. In this case you do not need to know anything about the structure of the device being developed. You only need to describe the behavior of the design model. When drawing a schematic you may be able to use some vendor's macro libraries containing the most popular devices such as counters, decoders, encoders, etc., and therefore avoid unnecessary efforts developing those basic structures. But on the other hand you may obtain vendor-specific HDL libraries containing the same basic structures and at the same time preserve full independence from any vendor. It is worth stressing that very large designs are more efficiently managed with files written in the HDL because you can have library files containing large numbers of components, while the schematic macro libraries usually use one file for each macro structure. This way, you can quickly run out of disk space having all the macros stored in separate files, especially when a large project is designed. Finite State Machines are excellent for control circuits. They represent the control flow in a project that is similar to the human way of thinking. Thus, they are very easy to follow and almost selfexplanatory. In addition, they automatically generate HDL code that precisely describes the state machine behavior and avoids any unexpected states. Active-HDL provides you with a State Machine Editor, that quickly and effectively converts any state machine into an HDL code. In real, working on large designs you will need all types of files: Schematics which are excellent for the top-level hierarchy model because of their readability. State machines which are perfect for the control flow description. HDL files which are universal and exchangeable.
Since a combination of all the available techniques gives you the best results, you should familiarize yourself with each of them.
25
Design Management Overview

Introduction
The design process may seem simple when there are only a few files to manage. However, when a design is comprised of many different files located in different folders, you may easily lose track. Active-HDL has several specialized tools for managing your design files. With the Design Wizard, you can create new files, avoiding hard work and confusion. In the Design Browser window you can easily attach old files and create new files or folders, the Workspace/Design Explorer in Active-HDL will help you to easily navigate between different designs.
Design Wizard
The New Design Wizard is a tool that helps in creating the skeleton of new design and adding new files to a project.
The New Design Wizard Window
Users who have created designs in the Active-CAD software can import them to Active-HDL. By selecting Import a design from Active-CAD a whole design can be imported to the Active-HDL environment for additional modifications.
27
Application Notes
The Resource Files Window A new design does not mean completely new files. The New Design Wizard allows you to add existing files to the design. The New Design Wizard window also allows you to configure the synthesis and implementation tools that will be used during the design evaluation process. In this window you can also specify the default HDL language and the Block Diagram configuration.
The Additional information window. In the next window you can specify the design name, location of the design folder, and the name of the default working library.
28
This Wizard is a very handy tool that saves time at the initial stage of the design development process.
Design Browser
The Design Browser window displays the contents of the entire design in a user friendly environment. This is the place where you can add or remove any source files. With one glance at the model hierarchy tree you can check which files are out of date and which contain errors. The Design Browser window allows you to select the top level design of the model hierarchy. All functional macro files are executed from here by invoking simple context menu commands. By double-clicking selected files, the Design Browser displays its contents in the appropriate editor window. During the compilation and verification process the Design Browser window displays all signals and signal values for the selected entity. The Design Browser window consists of three tabs: this tab shows resource files attached to the design and the contents of the default working library. this tab displays the HDL structure of the design extracted from the source files and HDL objects (signals and variables) within the selected design region. this tab displays folders containing the simulation log files and saved waveform files.
The Files Tab The upper part of the Files tab shows resource files of the current design. Each file is represented by a separate icon. The shape of the icon depends on the resource file type as shown above. In the case of HDL source files and state diagram files, the color of the icons brings additional information about the file status: Successfully compiled Not compiled or modified after the last compilation Errors occurred during the last compilation Compiled with warnings
29
Application Notes The Files tab shows design units contained in various specific source files. The name of the design unit currently selected for simulation is displayed in bold. The bottom part of the Files tab displays design units contained in the default working library. The list box located at the very top of the tab allows you to select the top-level design unit from a list of design units available in the default working library. The top-level design is displayed in bold. As always, you can also choose the top-level design in another way, by right-clicking any of the source files.
The Design Browser Window The attached resource files are: VHDL Source Code (vhd;vhdl;vhq;tvhd;vho;vhm;vhi), configurations, and testbenches Verilog Source Code (v;vei;veo;vo;vm;vmd;vlb;vlg) and testbenches C/C++ Source Code (cpp;c;h) Verilog Value Change Dump (.vcd) State Diagram (.asf) Block Diagram (.bde) BDE Symbol (.bds) Waveform File (.awf) List File (.lst) Macro (.do) SDF File (.sdf, .sdo) EDIF Netlist (.edf, .edn, .edo) Viewlogic Schematic (.1) TCL Script (.tcl) Active-CAD Test Vector (.asc) Active-CAD Project (.pdf) XNF Netlist (.xnf) Basic Script (.bas) Perl Script (.pl) Drawing (.afc) Bitmap (.bmp) HTML Document (.htm)
30
Design Management Overview Text (.*) External file
State Diagram and Block Diagram files are displayed together with the associated generated code. The context menu invoked by right-clicking from within the Files window allows compilation of the entire project or just selected folders. It also allows for removing files either from the project or disk. In case files contain macros, you can execute them from within the Files tab window.
The Structure Tab The Structure tab is divided by a horizontal split bar. The upper part shows the hierarchical structure of the top-level design unit. The lower part displays objects defined within the design region selected in the upper part of the tab. It is divided into several columns which show the object name, VHDL type or net type, current value, previous value, and last event time. The kind of the object (signal, variable, constant, port, generic, file, net, register, parameter) is indicated by the appropriate icon displayed next to the object name. To view objects from a specific region of the design, you must select the appropriate hierarchy branch in the upper part of the Structure tab.
The Design Hierarchy Structure (VHDL) The labels displayed next to the icons are extracted from the source code. You may also view the source code of the entity or process by right-clicking and selecting the Open command from the context menu. The Structure window has such editing features as dragging signal names from this window and dropping them into the Watch, Waveform, and List windows.
31
Application Notes
The Resource Tab The Resource tab is comprised of three default folders: List - with list files generated during simulation Logs - with log files from Console, Simulation, Find and Compile windows Waveforms - with waveform files
You may add new folders, for example containing different document files, by right-clicking in the Resources window. Different document types are displayed with different icon shapes.
Workspace/Design Explorer
The Workspace/Design Explorer window provides a means for efficient management of projects, so that you do not have to worry about the physical location of design files on your computer. There are functions that allow you to create and remove folders, add shortcuts to existing projects, create new ones and copy any project to a new destination folder. The Workspace/Design Explorer is invoked by selecting the Open Workspace option from the File menu. By default, all sample designs are stored in the /My_Designs/Samples_61/ folder, created during the installation.
The Workspace/Design Explorer Window Each design/workspace is represented in the Workspace/Design Explorer window by a shortcut icon. A design/workspace may have several shortcuts. The Workspace/Design Explorer allows you to group the shortcut icons into folders. Note that these folders have nothing to do with file folders in which designs/workspace are stored. The left panel of the window displays the hierarchical structure of the shortcut folders. The right panel shows the contents of the currently selected folder. The status bar displays the name and path to the design/workspace description file of the design icon currently selected.
32
Design Menu The Design menu allows you to perform the same operations as the context menu. In addition, there are unique commands providing for new libraries creation and customization of the project settings. You can also add currently opened documents to the design project folder.
The Design Menu In the Design Settings window you can set additional options. The window is divided into the following tabs: General - selecting the top-level design unit for simulation and block/state diagram HDL configuration VHDL/Verilog - setting the working parameters for the VHDL and Verilog compiler SDF - displays files with timing specifications and sets the target region of the design Simulation - provides specific options for VHDL and Verilog simulation, disabling VITAL glitches and warnings from the SDF file reader, as well as memory management settings Trace/Debug - provides settings for the Post Simulation Debug mode Verilog PLI - handles DLL libraries for PLI Applications EDIF - handles libraries needed for compilation and simulation in the current design Code Coverage/Profiler - allows you to specify the Code Coverage and Profiler options
33
Application Notes
The Design Settings Window Another useful option in the Design menu is the Backup Revision. It is often necessary to backup a design in its current state, especially when you are going to make major changes. You may even accidentally delete some files that are needed for simulation. It is recommended to keep backup files for your own protection. Having backup revisions saved at different stages of the development process allows you to trace changes in the design and develop several design versions, etc. Active-HDL allows you to save an unrestricted number of revisions for each design. Each revision is identified by its number automatically assigned during creation of a revision. You can also add an optional label and comments to each design. It is impossible to mix revisions created in Active-HDL for different designs. When you need to restore one of the previous revisions, you should use the Restore Revision command. The operation replaces the current design with the selected revision. Note, that this operation will remove the current design. If you plan to return to it, save it as a new revision before using the Restore Revision command.
The Backup Revision Window The Create Library option from the Design menu invokes the New Library Wizard window. The wizard simplifies the library creation process. You can insert files with VHDL code or state diagrams to the new library or create an empty one. The Wizard helps you locate the desired files and guides you through the whole process.
34
Archiving designs
To prevent any accidental design file deletions and to provide you with the additional exchange and backup options, Active-HDL comes with the Archive Design feature that allows archiving the design in a single ZIP archive file. By default, the file name is identical with the design name.
Archiving the design As you can see in the figure above there is a check list where you can specify what files should be included in the archive file. To restore the design use any tool that accepts the ZIP archive format.
Conclusion
In a typical design, resource files are created at different stages of the design process. Many of designers first create behavioral HDL files and testbenches, then import the structural design files and timing specifications for the simulation. Without a smart plan the user may end with stacks of files in one folder and no idea where the required ones may be found. As described in this application note, Active-HDL provides for efficient design management. In a situation when there are various design versions, you may lose the track of files that belong to each design version. Active-HDL allows you to create any number of project backups to prevent accidental file removals or modifications. The user can change the settings of the entire project with minimum effort, by checking appropriate options in the Settings window. The top-level design model can be changed within the Design Browser window, invoked from the context menu. Active-HDL offers the user several ways for executing the same commands. Less experienced users may prefer the menu commands and the more experienced ones may find the context menu the fastest way for executing any action. Whatever the users experience with CAD software is, he or she will certainly find the Active-HDL environment user-friendly and efficient.
35
Handling Libraries in VHDL, Verilog, and EDIF

Introduction
This chapter describes how to handle libraries in the Active-HDL environment. The purpose of this note is to familiarize you with the concept of the library and to teach you how to efficiently manage the library contents. The simulator does not simulate the HDL code directly. First the design sources must be compiled into a working library which is then simulated.
Libraries in VHDL
A design entity you are going to simulate must be compiled into a library first. Only the data stored in a library after successful compilation can be read by the simulator. A library can be a working library, a resource library, or both. A working library is the library into which the library units resulting from the analysis of a source file are placed. A resource library is a library containing library units that are referenced within the source file being analyzed. Only one library may be the working library during the analysis of a source file; in contrast, any number of libraries (including the working library itself) may be resource libraries during such an analysis. Logical names of resource libraries are listed in the library clause preceding a design unit in source code. For example, the following statement: library IEEE,PRIMITIVES; makes all design units residing in libraries IEEE and PRIMITIVE visible to the design unit that follows the statement. In addition, each design unit is assumed to be preceded by the following implicit statements, even if they do not appear in source code: library STD, WORK; use STD.STANDARD.all; The first statement makes visible design units residing in the standard library STD and in the working library. The logical name WORK always stands for the working library, that is, the library into which the source file is currently being compiled, irrespective of the actual logical name of this library. The second statement makes visible all declarations in the package STANDARD. As for the working library, you can set it individually for each source file of a design using the File Properties dialog box. By default, all source files are compiled into the default working library. Example Assume the file Simple.vhd contains source code listed below and is compiled into the library TEST: library IEEE, PRIMITIVES; use WORK.GLOBAL_SIGNALS.all; use PRIMITIVES.GATES.all; entity CELL_X is ... end entity CELL_X; The CELL_X entity can reference design units residing in libraries: IEEE, PRIMITIVES, TEST (here TEST = WORK). All declarations contained within packages GATES (in library PRIMITIVES) and GLOBAL_SIGNALS (in library TEST) are also visible.
37
Application Notes
Libraries in Verilog
Neither the existence nor the rules of use of libraries is defined in the currently available Verilog language standard. Some tools use Verilog libraries while others do not need them. Active-HDL is a simulation environment supporting several different HDLs (VHDL, Verilog, and EDIF netlists). To keep possibly uniform rules for all the supported HDLs, Active-HDL requires use of libraries also for Verilog and EDIF. A Verilog module you are going to simulate must be compiled into a library first. Only the data stored in a library after successful compilation can be read by the simulator. Specific modules of a hierarchical Verilog design can be compiled separately and in any order. Compilation of each module creates a single library unit in the target library. Like in VHDL, the target library into which a source file is being compiled is said to be the working library for this file. When the simulator loads the top-level module, it must also load all the modules instantiated therein and in the underlying hierarchy levels. Verilog itself does not provide mechanisms for specifying the resource library or libraries from which the hierarchically lower modules are to be loaded. Instead, Active-HDL searches the default working library and the libraries listed on the Verilog Libraries tab of the Design Settings dialog box. You can add any attached library to this list. If a library you want to add is not attached, you must attach it first using Library Manager.
Libraries in EDIF
If you want to simulate an EDIF netlist with Active-HDL, you must compile it into a library first. Compilation of hierarchical netlists produces separate library units for the top-level cell and for the component cells. All the library units are inserted into the default working library of the current design. Like in VHDL, the target library into which a netlist file is being compiled is said to be the working library for this file. When the simulator loads the top-level cell, it must also load all the cells instantiated therein and in the underlying hierarchy levels. Non-primitive cells are searched for in the default working library of the current design. As for the primitive cells, EDIF netlists contain explicit specification of libraries from which they are to be loaded. The simulator uses this information to load the complete design.
NOTE: To enable simulation of EDIF netlists generated by different tools, Active-HDL allows remapping of cell names, pin names, and library names appearing in primitive cell instantiations. Such a remapping allows the use of reduced set of universal primitive libraries and is performed automatically during compilation of netlist files. The description of the remapping rules resides in the Edfmap.ini file stored in the $Aldec\Dat folder ($Aldec is an Active-HDL environment variable that stands for the Active-HDL installation folder).
A tool that allows you to view and edit libraries and their contents, is Library Manager, described in greater detail later in this chapter.
38
Handling Libraries in VHDL, Verilog, and EDIF
Library Units
The structure of Active-HDL libraries evolved from VHDL. A library is a storage for library units, that is, compiled design units that can be loaded into the simulator and simulated. There are two categories of library units: primary and secondary. Secondary library units are inseparably connected with primary units. In other words, a secondary design unit cannot exist in a library without its primary unit. The following is a list of library unit types in Active-HDL.
Language Entities
Primary Units
Secondary Units Architectures Architectures result from the compilation of architecture bodies. An architecture describes the contents of the corresponding entity. A single entity can have several optional architectures. Package Bodies Package bodies result from the compilation of package bodies. A package body is an extension of the corresponding package.
Entities result from the compilation of entity declarations. An entity can be simulated only in conjunction with its architecture. Packages VHDL Packages result from the compilation of package declarations.
Configurations Configurations result from the compilation of configuration declarations. Modules Verilog Modules result from the compilation of Verilog modules. Cells EDIF Cells result from the compilation of EDIF netlists.
The icons displayed in the above table are used to represent library units (=compiled design units) in Design Browser and Library Manager. Each library unit is identified by its logical name. The following rules apply to library unit naming: Primary unit names must be unique within a single library. Architecture names must be unique for a given entity. If two architectures describe different entities, they can have the same name. Package body names must be the same as the names of the corresponding packages.
39
Application Notes
Block Diagram Symbols

In addition to simulation data, Active-HDL libraries store graphical symbols, which are used to represent design units on block diagrams. Only primary units (except packages) can have symbols. Library Manager indicates for each primary library unit whether it has a symbol or not.
Library Units without Simulation Data

It is intuitive to regard a library unit as a result of compilation of a design unit, that is, a portion of HDL source code. However, Active-HDL allows insertion of library units into libraries also in different ways, which do not involve compilation at all. Library units inserted in that way do not have simulation data and cannot be simulated. The library contains only the information that the library unit identified by a given logical name exists and that the simulation data will probably be created later on. This mechanism is designed chiefly to enable creating new block diagram symbols in the topdown designing. When you employ the top-down methodology, you need to create symbols before defining their contents (empty symbols and fubs). Defining an empty symbol or fub creates a new primary library unit in the default working library. This unit not only has no simulation data but its type, which can be either VHDL entity, Verilog module, or EDIF cell, is not defined either. The type will get defined the moment you push into the symbol/fub to create its implementation. If it is a VHDL entity, you will also create a new architecture. Still, the library unit(s) corresponding to the symbol will have no simulation data because you have not compiled the implementation yet.
NOTE: The VHDL compiler treats units without simulation data as if they did not exist. For this reason, if you compile VHDL code referencing such units, the compiler will issue warnings that you have unbound components.
Physical Implementation
In Active-HDL, each design library consists of the following files: The library index file (with extension LIB), which contains a list of library units stored in a library. The library data files with fixed names 0<project_name>.mgf, 1<project_name>.mgf, 2<project_name>.mgf or 3<project_name>.mgf which contain the simulation data as well as symbols for the library units contained in the library.
The name of the library index file (without the extension) is said to be the physical name of the library. Libraries are referenced in source code by their logical names. Active-HDL associates logical names with physical names using the library list. This list contains assignments of logical names to library index files (with full file paths). A single library can have several different logical names, but one logical name can be assigned only to one library. You can edit the library list using Library Manager. Example The following entry appearing on the library list: loadable_counter C:\My_Designs\Loadable_Counter\Loadable_Counter.lib
40
Handling Libraries in VHDL, Verilog, and EDIF associates the logical name loadable_counter with a library comprised of four files: loadable_counter.lib, 0loadable_counter.mgf, 1loadable_counter.mgf, 3loadable_counter.mgf residing in the folder C:\My_Designs\Loadable_Counter.
System Libraries vs. Design Libraries

All Active-HDL libraries can be divided into two functional categories: system libraries and design libraries. The category of system libraries comprises: Standard VHDL libraries describing the predefined language environment (library STD) and multi-value logic system (library IEEE). FPGA Vendor-specific libraries and synthesis libraries.
System libraries are stored in the Vlib subfolder of the Active-HDL installation folder. This folder can be referenced in the Active-HDL environment by using the predefined $Vlib variable.
Default Working Library Each design in Active-HDL has at least one dedicated library referred to as the default working library. The name stems from the fact that all design source files are compiled into this library be default. The logical name of this library is the same as the name of the design. The library content is displayed on the Files tab of the Design Browser window. If you wish a source file to be compiled into another library, you should change the target library setting in the File Properties dialog box. The default working library is created automatically with each new design you create.
Post-Synthesis and Post-Implementation Libraries A single design library may be an insufficient solution for certain designs. Some third-party tools used for synthesis and place-and-route processing generate VHDL or Verilog files containing design unit whose names are identical to the design unit names occurring in the original pre-synthesis source files. The problem with such files is that you cannot compile the post-synthesis and/or postimplementation VHDL files without overwriting the library units obtained from the compilation of the pre-synthesis files. One possible workaround is to manually rename the design units in the post-synthesis/post-implementation files. However, this is a rather awkward solution, especially when you want to implement batch processing of the design. Active-HDL allows you to resolve the problem by setting up one or two additional design libraries dedicated to post-synthesis and post-
41
Application Notes implementation files. The additional libraries are created automatically in designs that use design flowcharts employing third-party synthesis and/or implementation tools. Clicking the button launching synthesis automatically creates a new library in the design. Similarly, if you click the implementation button, a library for post-implementation files will be added to the design. The contents of both libraries can be viewed on the Files tab of Design Browser. The post-synthesis library resides in the Synthesis subfolder of the design folder. Its name is a concatenation of the design name and string "_post_synthesis". The post-implementation library resides in the Implement subfolder of the design folder. Its name is a concatenation of the design name and string "_timing". NOTE: If you use a single third-party tools for both synthesis and implementation processing, you will need only one additional library.
Library Manager
Library Manager is designed to allow you manage Active-HDL libraries. You can perform the following operations on libraries and their contents: Creating new libraries and setting up their working mode. Attaching, detaching and deleting libraries. Editing logical names of libraries. Compacting end emptying libraries. Viewing the contents of libraries. Viewing source files of specific library units. Deleting specific library units.
The Library Manager window is shown below:
The Library Manager Window The Library Manager window contains two panels. The left panel shows a list of currently attached libraries and their parameters. It has four columns: Library - displays the logical name of the library. Mode - displays the working mode of the library. There are two modes: Read/Write (R/W) and Read/Only (R/O). Comment - displays an optional comment providing short description of the library contents.
42
Handling Libraries in VHDL, Verilog, and EDIF Directory - displays the library index file with the full path.
Standard libraries are attached to the list during installation. When you create a new library it is also automatically attached to the list. Default working libraries appear on the list the moment you open appropriate designs. The right panel shows library units contained within the library selected in the left panel. In addition, if you select a package, a list of object defined therein will be displayed beneath a horizontal split bar. The right panel contains the following columns: Unit Name - displays primary library units contained in the selected library. The library is selected in the left panel of the Library Manger window. Secondary Unit Name - displays secondary library units contained in the selected library. The only primary units that may have secondary units are entities and packages. For the remaining unit types, the column repeats the name displayed in the Unit Name column. This is logically justified because when such units are referenced from VHDL code in mixed designs, they are assumed to have "virtual" secondary units with the same name. Source Type - displays the type of the source document containing description of a specific library unit. If the primary unit is a VHDL entity, this column displays the type of the source file describing a specific architecture, not the entity itself. In the case of nonVHDL units, the information in the column applies directly to the primary library unit. The available source types are: Source Code (if the unit is described directly in VHDL or Verilog source code), Netlist (if the unit is described directly by an EDIF netlist), State Diagram, and Block Diagram. Target Language - indicates the language of the source code from which the library unit was effectively compiled. If the source type is either Block Diagram or State Diagram, the language displayed here is that of the source code that was generated from the diagram file. The available target languages are VHDL, Verilog, and EDIF. Symbol - indicates if the primary library unit has a block diagram symbol in the library. This information applies only to VHDL entities, Verilog modules, and EDIF cells. Simulation Data - indicates whether the library unit has simulation data or nor. Libraries may include library units that have no simulation data. For details on such units, see the topic Library Units without Simulation Data. If the primary library unit is a VHDL entity, the information in the column applies to its architectures, not to the entity itself.
Standard and user-defined libraries are denoted by a generic icon. Vendor-specific libraries are denoted by their own unique icons.
Conclusion
As described in this chapter, the VHDL libraries are the backbone of any design. Because you can use the already tested and verified standard libraries, the design process is simpler and more efficient. By using vendor-specific libraries containing optimized entities, your design is far better than the one created from scratch and you obtain the best results while working with vendorspecific libraries. Each design is compiled into the project's library before it is simulated, therefore the need for an efficient and easy-to-use library management tool is imperative. The Library Manager from Active-HDL fulfills these requirements, allowing you for fast and reliable administration of library files. By executing simple context commands you can create, attach or remove selected libraries in a short time. To prevent libraries from accidental modifications by assign to them the Read Only attribute.
43
Simulator Overview
Introduction
The design verification process can be tedious and time-consuming. It gets worse when the design is developed over a period of time and the intermediate simulation results are saved in text files, which are often difficult to read and follow. To ease your work, Active-HDL provides you with a graphical simulator that has many outstanding features. Even the most powerful simulation tool would be of limited value to design verification if it did not provide a user-friendly graphical format for viewing simulation results. Active-HDL has its own Waveform Editor with many built-in viewing features, these can enhance the management of simulation results.
Outstanding Functionality:
The Active-HDL is a context and easy to use tool equipped with many powerful features. To make your work easier, Active-HDL provides simplified operations for: adding and removing signals applying stimulators constraining the set of toggled values editing waveforms loading, saving and printing waveforms
Adding and Removing Signals Before you start any simulation you must select signals that represent the input and output ports of the tested model or internal signals. There are several different methods of adding signals to a Waveform Editor. You can add them by dragging their names from the Design Browser window while the Structure tab is selected. You can also select signal names in the same way you select files in the Explorer window of the Windows system. Another method of adding signals and ports is to right-click in the Waveform Editor window and select the Add Signals option. For those who prefer typing commands, there is a way to add signals from the Console window by typing Wave signal_name and pressing the Enter key. You may then add one signal at a time, including all signals from a process or all signals of your root design.
45
Application Notes
The Active-HDL Environment If you added a wrong signal or want to remove one, you can do it by selecting the desired signal name in the Waveform Editor window and while it is highlighted pressing the Delete key. The other way to delete a signal is to right-click on its name and select the Delete option. By right-clicking the mouse in the right-hand side of the Waveform Editor window the signals names are displayed which gives you access to the following commands: Stimulators - allows the selection of a stimulator for the selected signal Add Signals - allows adding the signals to the Waveform Editor window Merge Signals/Split Signals - allows grouping and collapsing signals to/from virtual buses Insert Empty Row - allows to separate two waves by inserting an empty row Create Expression Signal - allows to insert to the waveform a logical expression (signal) Cut/Copy/Paste - standard edition operations Hide/Show - allows to hide or display the selected signal(s) Delete - allows deleting selected signal(s) Clear Waveform - Clears selected waveforms currently displayed in the Waveform Editor window Compare selected - allows to compare two selected signals in the current window Find - allows to find the specified value or text in the currently opened waveform window View Declaration - displays the declaration of the selected signal in a code View in Dataflow - displays the selected signal in the Dataflow window Properties - enables specification of the properties for the selected signal Follow Object - opens the pull-down menu that contains the list of processes to follow Previous/Next Object - allows to browse the history of followed objects
46
BASIC Scripting Capabilities
The context menu in the Waveform Editor window
Applying the Stimulators Having all signals needed for simulation selected in the Waveform Editor window, you can now assign stimulators to them. To do so select any signal name in the Waveform Editor window, right-click and select the Stimulators option. The same result is achieved by clicking the Stimulators icon. In the Stimulators window (Figure) you can choose between different stimulator types. Stimulators will drive your selected signals with the desired values.
The Stimulators Window To learn more about different types of stimulators please refer to the Using Stimulators chapter.
Constraining the Set of Toggled Values If you chose a Hotkey stimulator for a signal you may have to constrain the set of values between the hot key toggles. The default set of values is comprised of 0 and 1. However, you may expand it by adding any valid logical values for the signal. For example if the signal A is of the Std_Logic type you can add additional logical levels such as X, U, Z, etc. But if a signal is of Bit type then the default set cannot be altered, because the Bit type has only two logical levels 1 and 0. When applicable, should you select more than two logical values, toggling of the Hotkey would select the available values in a sequence.
47
Application Notes
The Default Set of Toggled Values
File Operations In the process of design verification, you can develop signal waveforms that may be useful for future applications. Active-HDL allows saving such waveforms in a file. To save waveforms in a file, select the Save as option from the File menu. Saving results in a file is great for documentation purposes. Those files can be used in repetitive design verifications as test vectors. To load a file with waveforms, select the Open option from the File menu. You can print the simulation results and attach them to your reports by selecting the Print option from the File menu.
Exporting simulation runs The results of the simulation run can be exported into a text file either in the tabled format (.vec) or as the VHDL or Verilog processes describing the signal behavior. Such signal descriptions can be used for automatic testbench generation. To export the waveforms into a file, use the Export Waveforms option from the Waveform menu.
Rich Viewing Capabilities:

Active-HDL provides many viewing options that can be customized to your own needs: arranging signal sequence expanding and collapsing buses changing the signal display mode changing signal colors adding comments adding expressions overlapping results changing cursors changing time scales displaying glitches measuring time events snapping to grid or event
Arranging the Sequence of Signals Since simulation results are independent from the sequence of signals in the Waveform Editor, you can rearrange these signals in a free manner, preserving all results and not stopping the simulation. To rearrange signals, drag the selected signal to its new position. If it is done properly, the red line above the dragged signal moves along as you drag the signal. You can also arrange
48
BASIC Scripting Capabilities signals the ascending or descending alphabetical order. Click the Names tab several times and watch the behavior of the window. You can also sort the signals with decreasing or increasing values by clicking the Value tab.
The Alphabetical Order
Expanding and Collapsing Buses Having all signals displayed in proper order allows you to expand or collapse such composite signals as buses. Some users find it easier to follow the changes when all bus wires are independently displayed in the Waveform Editor. Others prefer to track the behavior of a composite signal when it is collapsed into one piece. Active-HDL allows you to do either with just one click. Composite signals are displayed differently because they have a little square to the left of them. When such a signal is expanded it displays a minus sign. One click on that sign makes all the sub-signals collapse. Collapsed signals display a plus sign allowing you to then expand the bus.
Bus And Signal Display
Changing the Signal Display Changing the signal display is another useful feature of Active-HDL. There are three shape formats for signals: analog, literal and logical. The literal and logical formats can also be displayed with different radix: hexadecimal, decimal, octal and binary. You can choose between options by right-clicking the selected signal and choosing the Properties option from the invoked context menu. That is, however, not all of your options. You can change the colors of the simulation Viewer. By choosing Preferences in the Tools menu you can customize the look of the Waveform Editor to meet your needs. By default, all signals are drawn as dark blue lines on yellow background. However, you can draw any signal in the desired color by selecting the Properties option from the Edit menu. The same window appears after right-clicking any signal and selecting Properties from the context menu.
Adding Comments To enhance the display of the simulation results making it more friendly and readable, Active-HDL allows you to add comments to the displayed waveforms. This allows you to keep track of the design in an organized manner. You may use the same waveforms in the future and intuitively
49
Application Notes recognize what the purpose of the original simulation was. When different people test the same design, it is simpler to have all the comments displayed on the waveforms. To add a comment to a waveform, browse the contents of the Waveform Editor to the desired location. Then click on the signal where you want to add the comment and select the Insert comment option from the Waveform menu or click the Insert comment Type the text that will be added to the waveform and press the Enter key. icon on the toolbar.
Simulation With Comments
Overlapping the Results Continuous verifications can be tedious and after a certain amount of time your perception may not be as sharp as at the beginning. Some of the details may be overlooked. To prevent this situation Active-HDL allows overlapping results from a previous simulation with the current simulation. To differentiate between the two simulation data, the previous results are displayed in white background while the new ones are drawn on yellow.
Overlapping Simulations
Changing Time Scale If you test your design with different clock frequencies, this may result in an unreadable display. Fortunately, Active-HDL can display signals in a user-selectable time scale to zoom on timing details. You can do it in several ways, either clicking the Zoom in or Zoom out icons or switching to Zoom mode. The Zoom mode can be selected by choosing the Zoom mode option from the context menu or from the Waveform menu and by clicking the Zoom mode icon in the Waveform Editor toolbar. Another way to switch to a Zoom mode is to right-click in the Waveform Editor and select the Zoom mode option. Finally, you can decrease or increase the time scale with simple clicks. If you left-click with your mouse then the time scale increases. However, if you left-click while holding down the Control key then the action is reversed and the time scale decreases. The same operations can be performed by right-clicking the waveform display and selecting either Zoom in or Zoom out from the context menu. The scope of the zooming area can be also entered using the keyboard, to do so click the Zoom range icon.
50
Zoom Mode
Displaying Glitches If you find results that you cannot explain, it is not necessarily an error. Active-HDL has a built-in option which displays glitches in the Waveform Editor. You can turn it on by disabling the Ignore glitches option in the Waveform field of the Preferences window. For example, with this option enabled, you can trace any errors that are due to incorrect setup or hold times. However, this option, if enabled, affects the comparison of simulation results.
Measuring Time Events Sometimes you may wish to measure a time period between some events. To perform such a measurement switch to the Measurement mode either by clicking the Measurement mode icon or selecting the Measurement mode option in the Waveform menu or the context menu which is invoked by right-clicking. Typically, measuring time between two events would be difficult considering the precision with which the simulation results are displayed. You can, however, do it as precisely as needed because Active-HDL has an option that snaps the cursor to events. This option is enabled by checking the Snap to event option in the Waveform field of the Preferences window. You can also check the Snap to grid option in the same window which snaps the cursor to the invisible mesh in the Waveform Editor window. To customize the grid, specify the grid options in the Preferences window.
The Preferences Window If you are not sure what each icon does, point to it with the cursor and wait for a second. A short message will appear describing the operation that the icon performs. On the other hand, if you point with the cursor on a signal in the Waveform Editor window and wait a while a signal
51
Application Notes declaration type will appear. To switch to the Select mode, choose the Select mode option from the Waveform menu or from the context menu.
Search Tools
After some time you may accumulate so many simulation results that you will not be able to easily manage them yourself. However, Active-HDL has options that allow you to quickly locate any event in the signals history. There are several options that allow to find a specific value or browse by selected items: by page by bookmark by value by text in comments by difference mark by time by signal event by rising or falling edge by constraint
Search by Value or Text You may find the desired signal value with minimum effort, by invoking the Find option from the Search menu. The same window will appear when the Find option from the context menu is selected. There are two options you can choose from. First, you may find the entered value by selecting the Find value option. Selecting the Find text in the comments will start a search of all comments for the text you have entered in the Find field. There is also an option for the direction of the search; click Forward or Backward to select the search direction.
The Find Window Search by Time If the results you are looking for should occur at a specific time you may go to that point by invoking the Go to Time window. It can be done by clicking the Go to selecting the Go to option either from the Search or context menu. icon in the toolbar or
The Go to Time Window
52
BASIC Scripting Capabilities For details on searching or browsing waveforms refer to the Basic Operations on Signals and Waveforms and Navigating and Measuring Timing chapters in the Waveform Viewer/Editor | Procedures section.
Search by Event Sometimes it is better to browse simulation results not by pages but by signal events. To perform this operation, click the Next event or Previous event icons in the Waveform Editor toolbar. It is also possible to switch between bookmarks which you can leave at any time during simulation, by clicking with the pointer on the time scale, leaving a blue marker. To switch between bookmarks, click the Next bookmark toolbar. or Previous bookmark icons in the
Comparison of Simulation Results The Waveform Editor also allows comparison of the simulation results. Signals for which the difference was detected are displayed in the Waveform Editor window with the red color. The icon enabling the comparison of signals is located in the upper part of the window. The previous simulation run results must be first saved in the project folder. In the case of differences in simulation runs an appropriate message is displayed.
Comparing simulation runs
Conclusion
Simulation is designed to accurately verify the behavior of logical circuits, so that you can be sure that they will operate properly after they are manufactured. The results on the other hand, though correct, may be hard to check if not presented in a graphical manner. A graphical simulator display provides a lot of well organized information and is user friendly. With rich viewing options, the Waveform Editor is a complete verification environment that allows you to freely customize the look of the simulation results. At the same time it provides for instant verification of the design changes. You can save time by working with graphical tools instead of text files. Having all results presented in the preferred graphical helps find errors within seconds, you do not even have to browse the results by pages. Active-HDL allows you to browse the simulation by events. Moreover this lets you find any value, text or time of simulation with no extra effort. Some users prefer to perform all the operations with the mouse, others find shortcut keys superior to menu commands. The Active-HDL commands will suit everyone, because each operation can be performed in several different ways. Each time an action is performed, it is verified by the change of the shape of the cursor.
53
Application Notes

Introduction
This chapter describes how to create and execute files containing macro commands and BASIC script files. The Active-HDL macro command language is based on execution of BASIC scripts. By typing the command in the Console window you are actually executing the corresponding BASIC file. Every action and command menu in Active-HDL can be executed from the Console window. You can execute a macro file containing sequences of macro commands to perform complete simulation runs. Active-HDL also provides you with a graphical BASIC debugger that allows you to create and modify embedded script files.
Console Window
The Console window is an interactive input-output screen for entering of Active-HDL commands and displaying messages generated by Active-HDL tools. The Console window includes several tabs to separate messages generated by different tools. The Console tab displays messages generated by various tools. This tab also serves as an input for Active-HDL commands, which allow you to perform various operations in the application without using the GUI menus and toolbars.
The Console Window
List of Available Commands

Most of the implemented Active-HDL commands are invoked with parameters such as file names, signal names, line numbers, etc. After typing the help <macro_command> command in the Console window you will switch to the Active-HDL Help window with the list of all available commands. Here is the list of selected macro commands with a short description of their 1) functions :
abort acom addvar addfile adel adir
stops the execution of a macro file that has been interrupted by a breakpoint. invokes the VHDL compiler. adds variables defined by the set command. adds the specified file to the current design. deletes a design unit from a design library. displays the contents of the selected library.
54
alib amap architecture asim bd bp bs bsd cd change
creates a new design library. assigns a logical name to a design library. selects the specified architecture for the top-level design entity. invokes the simulator. deletes the specified below breakpoint. allows you to set and view breakpoints. If command parameters are omitted, the command will list all currently set breakpoints. Otherwise, the command sets a breakpoint in the specified file and at the specified line. sets a signal breakpoint. deletes a signal breakpoint. changes the current working directory. modifies the value of a variable. The simulator can do it only at a breakpoint or when it is paused after a step command. clears the contents of the specified tab of the Console window or the Console log file (Console.log) or document window (List Viewer or Waveform Viewer/Editor). clears the contents of the specified file. clears the contents of the specified library. closes the specified document window. launches the Code2Graphics converter. defragments and deletes obsolete data from the specified design library. compiles a specific source file or all source files attached to the current design. sets the specified configuration as the top-level design unit. restarts the simulation after a step or step-over command or a breakpoint. The continue command can be entered manually. It can also be included as the last command in a bp command string. creates a copy of the specified file. creates a project with the specified file name, configuration and path. decrements the value of the specified variable defined with the set command. displays information about the type of the specified signal, variable or constant disables code breakpoints (without removing). executes commands contained in the associated macro file, which can
clear clearfile clearlibrary close code2graphics compactlibrary comp configuration continue copyfile createdesign dec des, describe disablebp do
55
Application Notes
have any name and extension. Any error encountered during the execution of a macro file will interrupt its execution. drivers echo echofile edfcomp enablebp endsim displays in the Console window the current and scheduled future values for all drivers of the specified VHDL signal. If this signal is a type record or array, only the drivers for the first sub-element will be displayed. displays the requested message in the Console window. sends the specified message to the specified text file. invokes the EDIF netlist compiler. enables breakpoints that have been disabled by the disablebp command. waits for the end of simulation. Useful when you need to hold execution of a macro until the end of current simulation. sets the specified entity as the top-level design unit. To set the architecture, use the architecture command. By default, the last compiled architecture is used. provides for changing and displaying the current region/signal environment. analyzes the specified item and displays its current value in the Console window. This operation can take place at any time, but only if the simulator has paused at a breakpoint or after a step command. exports a waveform file into VHS or VEC format files. compares two list files and saves the result of the comparison to a text file. The list files can contain up to 250 signals. searches a file specified by the <input_file> parameter for a text string. is used for interactive assignment of stimuli to VHDL signals. There is no limit on the number of stimuli in a macro file. creates a macro command file containing a sequence of list commands with the names of the currently listed items and options for each signal. This file may be invoked with the do command to recreate the list window format on a subsequent simulation run. creates a macro command file containing a sequence of wave commands with the signal names in the Waveform window including their display options. You can reproduce the Waveform window format on the subsequent simulation runs by invoking the do command. generates VHDL code from a state machine diagram. generate a test bench for the selected design entity. displays the system clock time in the Console window. jumps to the line labeled with the specified parameter. Displays help on a specific Active-HDL command.
entity
env, environment
ex, exa, examine expwave fc findstring force
format list
format wave
fsm2vhd generatetb gettime goto help
56
if
executes the listed commands if the specified expression is true. Placing the command in a macro file requires that the keywords if, else, and endif are the first tokens on a line. The entire command must be entered on the same line when used in an interactive mode or in a breakpoint. increases the value of the variable. see goto. lists all HDL items (VHDL variables) and their values in the List window. If no port mode is specified in the list specifications, all interface and internal items will be listed. If no arguments are listed, the command will display the List window. cancels effect of any active force commands on the associated HDL items and causes reevaluation of their values. deletes all listed HDL items from the List window. removes the specified item from the Waveform window. used exclusively within macros. It specifies a command that will be executed upon encountering a breakpoint in the source code. If this command has no arguments, then no command will be executed when a breakpoint is detected in the macro source code. Instead, the associated bp command string will be executed. used exclusively within macros. It specifies a command that will be executed upon encountering an error in a source code. If the onerror command has no arguments then no command will be executed when a macro encounters an error. A combination of the onerror and resume commands will print an error message without halting the execution of the macro file. opens a file in the specified window. opens the existing project. when detected, the pause command halts execution of the associated macro. displays the name of the current working directory for Active-HDL disables or enables the quiet mode. In the quiet mode, message boxes are not displayed during execution of a macro. exits the simulator without saving data. However, prior to exiting the simulator, you will be asked for confirmation. specifies the default radix for all commands (change, examine, force, etc.). It is also used for displayed values in the List, Watch, and Waveform windows. erases specified design from the disk. erases specified file from the disk. reloads the design sections that have been changed and resets the
inc label
list (add list)
noforce nolist nowave
onbreak
onerror
open opendesign pause pwd quiet quit
radix removedesign removefile restart
57
Application Notes
simulation time to zero. The design sections that remain unchanged will not be reloaded by this command. This speeds simulation on subsequent runs. run runexe runscript savealltabs forces the simulator to perform the specified number of time steps. runs an executable (*.exe) or batch (*.bat) file. executes a script from the Console window saves information from all tabs of the Console window to a log file (Console.log). produces user-defined variables. Returns a list of all user-defined variables, if used without arguments. Use a dollar sign ($) any time you reference a command line to a user-defined variable.
set
setlibrarycomment attaches a comment to the specified library. setlibrarymode source sets the access mode for the specified library. displays the selected HDL source file in the HDL Editor window and is used for setting a breakpoint in a file other than the one currently displayed in the HDL Editor window. forces the simulator to step to the next or desired HDL statement (descending into the subprogram body). Optionally, the VHDL procedures and functions can be skipped. Time advances to the next scheduled activity. stops the current simulation. subtracts variables defined by the set command. logs the history of selected signal in an internal data base. The base is the source of data for the List and Waveform Editor output windows. Signals that are displayed using the list and wave commands are automatically recorded in the data base. A signal which has been logged and is subsequently added to the List or Waveform Editor window will have its complete history back to the start of logging. echoes commands executed in a macro file. The current setting is reported if no argument is specified. opens the specified window. In case of non-document windows (Console, Watch, Processes, Library Manager, Design Browser), the command also closes the specified window (if opened). invokes the Verilog compiler. used for adding signals to the Waveform window. compares currently loaded waveform with a waveform saved in a file. displays information about the system environment, which is useful for debugging problems when the simulator cannot find the required libraries or support files.
step
stop sub
trace
tran, transcript
view vlcomp wave wavecompare where
58
write
1)
Saves the contents of the List window, Waveform Editor window, or Block Diagram Editor window to a file in its native format.
See the updated list of macro commands in the Active-HDL Macro Language chapter.
Files with Macro Commands

Active-HDL allows you to create macro files that contain sequences of macro commands. By executing such a file you can run an entire simulation provided you had earlier prepared all the required files such as model description, test vectors, etc. Let's look at the example macro file used for verification of the Counter project that is included with Active-HDL. The upper part of the file rebuilds the project in quiet mode, loads counter description files COUNTER8.VHD and test bench file TESTBENCH.VHD, and selects the TESTBENCH_ARCH as the top architecture. The lower part of file initializes the simulator, adds the signals to the Waveform Viewer and runs simulation. As you can see, a macro file is rather easy to follow once you know the macro commands. Example: A macro file FUNCTIONAL.DO included in project Counter # rebuild whole project savealltabs quiet on acom counter8.vhd acom testbench.vhd asim testbench TESTBENCH_ARCH # initialize simulation wave wave CLK wave RESET wave CE wave LOAD wave DIR wave DIN wave COUNT run -all endsim quiet off
Software execution
The Console window allows you to execute external files such as system commands, software tools, etc. You may even run the placement and route tools for the project being developed without invoking the GUI of the appropriate software. This is a good way of developing design layouts, because it saves time. This method, however, requires proficiency in using the software tools, because you have to have in-depth knowledge of the software you are using.
Conclusion
All macro commands in Active-HDL are based on BASIC script files stored in the SCRIPTS directory. You can invoke any menu command from the Console window. There is also an option
59
Application Notes allowing you to execute a script file containing sequences of commands that can perform the entire simulation process. Moreover, by using the BASIC programming language you can develop scripts for the frequently used routines and common operations. For example, when testing design behavior at different stages of development, you can improve your productivity by creating a BASIC script file that automates the execution of repeatedly invoked commands such as opening the project, initializing the simulation, applying the stimulators, saving the results in the file, etc. BASIC language is not hard to learn, however, it requires a good knowledge of the system behavior. Users may relay on the macro commands provided with Active-HDL, moreover, they may try to enhance the functionality of Active-HDL with self-written scripts. The script files are not easy to write, but the effort you put in developing them will return higher productivity in future. For example you may save a lot of time testing libraries, where the same actions are performed over and over. However, you may spend some time developing the scripts which will allow automatic testing of these libraries.
60
Tcl/Tk Scripting
Introduction
Tcl (Tool Command Language) is a simple scripting language for controlling and extending applications. Tcl together with its extension, Tk, provides a programming system for developing and using graphical user interface (GUI) applications. The interpreter engine built in Active-HDL supports version 8.0 of the Tcl/Tk standard. Tcl scripts can be invoked directly from the Console window as well as from the GUI (using user-defined menu items and buttons). The HDL Editor supports keyword coloring for Tcl/Tk scripts. However, there is no built-in mechanism for debugging these scripts.
Using Tcl/Tk Scripts

A Tcl/Tk script is a single text file containing a program created in the Tcl language (Tool Command Language). Such a script can be executed from the Console window by the runscript macro command : runscript <scriptname> [ <parameter_value> ...] You can pass optional command line arguments (separated by spaces) into the script, provided that a script expects them. If you are going to run this script from the Console window, the script file should be stored in the $DSN/src folder ($DSN is the Active-HDL environment variable that specifies the path to the directory of the current design). Otherwise, you will have to specify a full path to the script. If you are going to link a script to a user-defined menu item, the script file can be located anywhere since, in this case, you always specify the path. By creating your own scripts, you can extend the functionality of the Active-HDL macro language. In the Active-HDL environment, scripts are considered resource files. As such, they can be attached to designs like other resource files, e.g., source files. For more details, see Design Browser help (Files tab). You can create Tcl scripts using any non-formatting text editor. However, the built-in HDL Editor is the best suited editor for this purpose because it supports the keyword-coloring of the Tcl/Tk syntax. Note, however, that Active-HDL provides no debugging mechanisms for Tcl/Tk scripts.
Controlling Active-HDL from Tcl/Tk Scripts

By using the Tcl/Tk scripts you can achieve the same functionality as the one provided by the Active-HDL macro language. The following Active-HDL macro commands are implemented as Tcl functions inside the macros.tcl package:
acom add advdataflow add list add mem
copyfile coverage createdesign dec des
help if inc label list (add list)
sm_reset sm_session_cmd sm_win sm_prepare (VHDL)
61
Application Notes add wave addfile addvar adel adir alias aliaspar aliasswitch alib alog amap architecture asim bd bp bs bsd cc merge change clear clearfile clearlibrary code2graphics comp compactlibrary configuration describe design disablebp do drivers echo echofile edfcomp enablebp endsim entity env environment examine1) expwave fc findstring flushlogs force fsm2vhd generatemacro generatetb gettime goto gototime makeup (ucase) noforce nolist notrace nowave onbreak onerror opendesign pause psd quiet quit radix removedesign removefile restart run runexe runscript savealltabs set setactivelib setlibrarycomment setlibrarymode sm_cmd sm_prepare (Verilog) step stop sub tran transcript ucase (makeup) vcom vdel vdir view vlcomp vlib vlog vmap vsim vsimsado wave (add wave) wavecompare where workspace write
(*) Function examine in Tcl returns the value of the specified VHDL object in decimal format. No radix specification is allowed. All the functions listed above have the same arguments as their counterparts in Active-HDL macro language. A Tcl script can call another script of any type (BASIC, Perl, Tcl) as well as a macro file. To enable this, the following line should be included in the Tcl script file: package require ::aldec::scripter 1.0 To execute a BASIC script, use the following statement: ::aldec::scripter::ExecuteScript "runscript -bas <script_filename> <parameters>"
62
Tcl/Tk Scripting To execute a Tcl script, use the following statement: ::aldec::scripter::ExecuteScript "runscript -tcl <script_filename> <parameters>" To execute a Perl script, use the following statement: ::aldec::scripter::ExecuteScript "runscript -perl <script_filename> <parameters>" To execute the macro file, use the following statement: ::aldec::scripter::ExecuteScript "runscript -do <script_filename> <parameters>" In the above examples, <script_filename> stands for the name of the script file with the extension and a path. <parameters> denotes the optional list of parameters (if the script requires any). NOTE: The Tcl/Tk language syntax requires double backslashes in the path specifications. You don't need to provide a path to the script file if it is attached to the active design or it is located in the $DSN\src directory.
Example 1 # Use ::aldec::scripter package (access to scripter interface) package require ::aldec::scripter 1.0 # Hide the main window wm withdraw . # Execute a macro startup.do that is normally executed during # Active-HDL startup: package require ::aldec::scripter 1.0 ::aldec::scripter::ExecuteScript "runscript -do \$aldec\\script\\startup.do" Example 2 package require ::aldec::scripter 1.0 # prevent from echoing commands to the Console window ::aldec::RunCommand "transcript off" # turn on the "quiet" mode (no message boxes will be displayed) quiet on #initialize the simulation for the and2 module asim and2 and2 #add a0, a1, and y signals to a waveform window wave a0 a1 y # set stimulators for a0 and a1 signals force a0 0 0 ns, 1 100 ns, 0 130 ns, 1 150ns, 0 200ns force a1 1 0 ns, 0 110 ns, 1 140 ns, 0 200ns
63
Application Notes # perform simulation as long as Y signal value does not equal 1 # (and stop if simulation time exceeds 200 ns) set k 0 while {[examine Y] != "1" && $k < 20} { set k [expr $k+1] run 10 ns } # end the simulation endsim # turn off the "quite" mode quiet off # turn on command transcriptions ::aldec::RunCommand "transcript on"
Modulator Example
Active-HDL comes with a Modulator example, which employs a Tcl/Tk script to run an automatic simulation. Tcl/Tk scripts are executed in Active-HDL similarly to the macro command files. This is done by selecting the Tcl/Tk file in Design Browser window and then choosing the Execute command from the context menu.
Executing the Tcl/Tk script. After executing the Modulator.tcl script you will see the following window displayed in the center of the Active-HDL environment. The simulation is thus controlled from within the window by appropriate buttons and scroll bars. This method of providing simulation stimuli is more intuitive and efficient.
64
Tcl/Tk Scripting
Simulation window created in Tcl/Tk script language The remaining part of this application note explains the particular elements of the Modulator script responsible for creation of the window described above.
Initialization
Instead of manually forcing the input signal values in the Modulator example you can use the window described above. By clicking the appropriate buttons and sliding the scroll bars you can force required input stimuli and perform a 100 ns simulation steps. Each user action (sliding a scroll bar or pressing a button) is also signaled with a sound stored in a WAV file attached to the design. The initial part of the Modulator script contains declarations of the packages used later on. Apart from the scripter package containing Active-HDL macro commands, the mmedia package is declared as well. This package allows to use multimedia files such as graphics or sounds in the script. The set command sets the global dsn variable, which stores a path to the design (the value for this variable is taken from the Active-HDL environment by the GetVariable function stored in the scripiter package). The square brackets surrounding the set function call replace the call with its result. ## BEGIN SETTINGS ## wm withdraw . package require mmedia package require ::aldec::scripter 1.0 set dsn [::aldec::scripter::GetVariable "dsn"]
Compilation and Simulation

The acom is a Active-HDL macro command that compiles the design files while the asim initializes the simulation of the Modulator design. ## COMPILATION AND INITIALIZATION ## acom SinusGenerator.vhd acom CosinusGenerator.vhd acom SawGenerator.vhd acom Multiplier.vhd
65
Application Notes acom Modulator.bde asim Modulator The following code executes the open macro command that opens the wave1.awf file in the Waveform Editor window. The force command sets up a stimulator for the CLK signal. ## PREPARING FOR SIMULATION ## ::aldec::scripter::ExecuteScript "open" {-wave $dsn\src\wave1.awf} force CLK 0 0, 1 500 ps -r 1000 ps
Setting Up Windows
Tcl/Tk scripts can contain single line commands as well as procedures. Below are the procedures responsible for: positioning the simulation window shown earlier - positionWindow playing the selected sounds - ButtonSound removing the signal stimuli bound to the signals and ending the simulation - ExitProc
## GUI SETTINGS ## proc positionWindow . { wm geometry . +300+300 } proc ButtonSound {SoundNumber} { global dsn switch $SoundNumber { 1{sndPlay -async -nodefault [file "Default.wav"]} 2{sndPlay -async -nodefault [file "Minimize.wav"]} 3{sndPlay -async -nodefault [file "Recycle.wav"]} 4{sndPlay -async -nodefault [file "Exclamation.wav"]} 5{sndPlay -async -nodefault [file "Question.wav"]} 6{sndPlay -async -nodefault [file "WindowsExit.wav"]} } } proc ExitProc {} { noforce sinfreq noforce sinenable noforce sawfreq noforce sawenable noforce cosfreq noforce cosenable noforce clk endsim }
join $dsn src2 sounds join $dsn src2 sounds join $dsn src2 sounds join $dsn src2 sounds join $dsn src2 sounds join $dsn src2 sounds
66
Tcl/Tk Scripting
The code lines below represent a sequence of Tcl/Tk commands that create a simulation window with appropriate labels displayed. The positionWindow procedure sets the position of the window, next the ModulatorIcon.gif file is loaded by the image command. The frame command sets frames inside the window containing separate functional parts of the window. For example: labels, buttons, scroll bars, etc. wm iconify . wm deiconify . set . .button set . .label wm title . "MODULATOR ON Tcl/Tk" wm iconname . "button" wm iconname . "label" positionWindow . frame image -file label .labels -relief raised -bd 1 create photo Modulator \ [file join $dsn src2 images ModulatorIcon.gif] .labels.image -image Modulator
label .labels.msg -wraplength 5i -justify left -text "The Modulator contains three oscillators. The buttons labeled SIN, COS and SAW activate appropriate oscillators whose frequencies are controlled by the sliders located below the buttons. RESTART - restarts simulation. 100ns - advances simulation by 100 ns. EXIT - ends simulation and exits the dialog." pack .labels.image .labels.msg -side left -expand yes pack .labels -side top -pady 1 -expand yes frame .sinus -relief raised -bd 1 frame .cosinus -relief raised -bd 1 frame .saw -relief raised -bd 1 frame .buttons -relief raised -bd 1 pack .sinus .cosinus .saw .buttons -side left -expand yes -pady 1
Buttons
The buttons are created with use of the bitmap files stored in the project directory. Each button in the example has two positions: on - SinIn and off SinOff. To employ the button images you can use the image command. The image command is used to create, delete, and query images. image create photo SinOff \ -file [file join $dsn src2 images SinOff.gif] image create photo SinOn \ -file [file join $dsn src2 images SinOn.gif] .sinus.b1 configure -selectcolor [.sinus.b1 cget -background] .sinus.b1 select
67
Application Notes
Sounds
Depending on the current button state: pressed or released, the appropriate bitmap is displayed and a required sound is played as well. The button sounds are indexed and bound with the ButtonSound procedure. In the following example the ButtonSound command is invoked with 2 as a parameter, which means that the "Minimize.wav" wave file will be played every time the button is pressed. checkbutton .sinus.b1 -image SinOff -selectimage SinOn -variable SinEnable\ -indicatoron 0 -command "ButtonSound {2}"
Scroll bars
To create a vertical bar in the window you can use the following scale command: scale .sinus.scale -font system -orient vertical -length 200 -from 1 -to 200 -tickinterval 99 -label "MHz" -variable SinFreq -command "ButtonSound {1};set temp1"
Controlling the simulation

With the simulation window set up the user is able to control the simulation by clicking the appropriate buttons. The RESTART button executes the Restart Simulation command from the Simulation menu. Each 100NS button click invokes the Run100ns procedure that performs a simulation step. Below is the code that creates, binds the appropriate sounds (from the sound set defined previously) and controls the behavior of the RESTART and 100NS buttons. button .buttons.restart -font system -text "RESTART" -width 13 height 3 \ -command "ButtonSound {4};::aldec::scripter::ExecuteScript restart;" button .buttons.100ns -font system -text "100NS" -width 13 -height 3 \ -command "ButtonSound {5};Run100ns;" The Run100ns procedure uses globally set variables to force appropriate signals and advance the simulation for 100 ns. proc Run100ns {} { global SinFreq CosFreq SawFreq SinEnable CosEnable SawEnable force sinfreq $SinFreq force cosfreq $CosFreq force sawfreq $SawFreq force sinenable $SinEnable force cosenable $CosEnable force sawenable $SawEnable run 100 ns } label .buttons.label1 -text "" -width 10 label .buttons.label2 -text "" -width 15 -height 3
68
Tcl/Tk Scripting label .buttons.label3 -text "" -width 10 label .buttons.label4 -text "" -width 10 The EXIT button allows the user to end the simulation by invoking the ExitProc procedure which removes the bound signal stimulators and executes the endsim Active-HDL macro command. button .buttons.exit -font system -text "EXIT" -width 13 -height 3 \ -command "ButtonSound {3};ExitProc; destroy ;set end_tcl true" pack .buttons .buttons.restart .buttons.label1 .buttons.100ns .buttons.label2 .buttons.label3 .buttons.label4 .buttons.exit -side top -expand 1 wm protocol . WM_DELETE_WINDOW "ExitProc; set end_tcl true" tkwait variable end_tcl
Conclusion
The example described in this application note shows only several aspects of the Tcl/Tk scripting. See the Tcl/Tk Reference Manual in the Active-HDL Online Documentation (Help | On-line Documentation | References | Tcl/Tk Reference Manual) to find out more about powerful abilities of the language. As you may conclude, the Tcl/Tk scripts allow you to control the Active-HDL environment from within one file. There are lots of benefits of creating Tcl/Tk scripts. Once created, they can be easily modified to supply other designs with required stimuli. Projects containing Tcl/Tk scripts can be controlled easily by beginners as well as advanced users.
69
Creating FPGA and CPLD Designs

Introduction
This chapter describes typical approach to designing FPGA and CPLD devices in Active-HDL. The purpose of this note is to provide you with a basic understanding how Active-HDL operates as a complete design environment, including an HDL editor, State Editor, Block Diagram Editor, simulation and design implementation or synthesis. The document does not focus on any specific FPGA or CPLD vendor. Detailed guidance on designing vendor-specific parts is the subject of vendor-specific tutorials.
Resource Files
In a typical FPGA/CPLD design, Active-HDL operates on resource files such as source files, SDF files, macro files, etc., created at different stages in the design process. Most designers first create behavioral VHDL files (used for synthesis) and test bench files that are used for model verification. After implementation or logic synthesis of the behavioral files next step is to import into Active-HDL the structural design (i.e. netlists) and timing files (i.e. SDF) generated by the synthesis and Place&Route tools for timing simulation. Since all these files reside within the same design it is a good idea to group files into folders for better clarity: Functional - contains groups of files created at the initial stage of the design process. It includes source files intended for synthesis and test benches used for design verification. Timing - contains groups of files generated by the FPGA/CPLD implementation tools. They are used for timing simulation and usually comprise: Structural VHDL files modeling the physical netlist SDF files containing timing data used to annotate timing models.
Simulate - contains groups of macro files launching functional and timing simulations. These macro files contain Active-HDL commands. Implement contains groups of macro files used for launching synthesis and Place&Route programs (see section on Synthesis).
The Design Browser allows you to create any number of folders. You can name these folders to best describe their contents.
71
Application Notes
The Design Browser Window
Behavioral Simulation (Functional)

The initial VHDL description of the design undergoes functional verification in the behavioral HDL simulator. The most important task at this stage of the design process is creation of appropriate test vectors. Test vectors provide simulation input for the design, in response, the simulator produces design outputs. Evaluation of the output response provides the answer to whether or not the models behavior satisfies the designers expectations. In Active-HDL, you can apply stimulus to the input models in three different ways: By using the Stimulators tool in the Waveform Editor window. The dialog supports several different techniques of defining the stimulus waveforms. The contents of the Waveform Editor window are saved to a file, which can be used later on in other simulations and to generate test bench files. By creating a macro file containing sequences of force commands. By creating a VHDL test bench file. A test bench file contains a design entity/module as a host environment for the tested design entity. Depending on the degree of design complexity, the test bench can automatically produce input stimulus and compare the output response with the previously defined output vectors.
Creating Test Benches

The figure following illustrates the concept of a test bench.
The Test Bench Structure A test bench forces the desired stimuli on the inputs to the tested design unit (Unit Under Test = UUT) to enable functional verification of the design. In addition, advanced test benches can perform a comparison of the output response with a previously defined test pattern. Active-HDL supports automatic generation of test benches based on waveforms that have been previously created in the Waveform Editor window and saved to a file. The test bench file
72
Creating FPGA and CPLD Designs contains a test bench entity declaration and its own architecture body. The architecture body contains: Component instantiation for the UUT entity. Local signals mapped to ports of the UUT entity. A process statement that forces stimulus on the local signals connected to input ports of the UUT entity. This statement is included only if a waveform file was specified as a source of test vectors. Otherwise, the user has to supply the appropriate process.
Re-using Test Benches from Functional Simulation

It is possible to use the same test bench for timing simulation that has been used for functional simulation. The shortest way to do so is to write a configuration declaration that binds the architecture body obtained from the Place and Route tool to the UUT entity. Such an approach is applicable only if the entity obtained from the Place and Route tool matches the UUT entity in the initial VHDL description with respect to ports and generics.
Interface to Logic Synthesis in Active-HDL

After the design has been verified at the behavioral level, it should be synthesized in order to obtain a netlist for physical implementation. Active-HDL provides an interface to synthesis tools the Console window. The user can write macros, executed in the Console window, that will call external synthesis programs (Exemplar, Synplify, FPGA Express) and pass data to and from them. Moreover, it is possible to extend the macro language by adding user-defined basic scripts that implement new commands. In this way, it is possible to create a user-customizable interface to external synthesis and Place&Route tools. The only restriction arises from the fact that external programs are called along with parameter specification from the command line. Not all programs can work in such a mode.
The Design Flow Diagram
73
Application Notes Different synthesis tools have their specific sets of options. The information on these options is available in proprietary documentation for specific tool. To facilitate calling up the external software the user can specify new Tools option invoking the synthesis tool.
New option for FPGA-Express execution Some synthesis tools can export synthesized netlist in the VHDL format. Simulation of such VHDL code, and comparison with the functional simulation results of the initial behavioral description gives you additional verification of the design. Active-HDL provides direct interfaces to a variety of synthesis and Place and Route tools for many vendors and target devices. Active-HDL can import Active-CAD projects into its environment.
Design Implementation
The netlist produced by synthesis tools is an input for Place and Route tools. The final result of running a Place and Route tool is a bitstream file that can be downloaded into a programmable FPGA device. Most FPGA/CPLD vendors place and route tools generate a physical VHDL model (Vital) of the implemented design which can be used for timing simulation. The model is structural and based on primitive models supplied in the vendor-provided VHDL libraries. (Appendix A provides a list of vendor-specific libraries shipped with Active-HDL.) Most libraries with timing primitive models are based on VITAL procedures. Primitive models used for timing simulation possess a set of timing parameters (passed on to the model through generics). Two methods are used for defining the value of these generics: The actual values are defined directly in the VHDL code by the generic map aspect. The actual values are specified in separate files, provided in the SDF (Standard Delay Format) format.
Adding Post Place-and-Route Files to Design

Using Design Browser, attach to the files obtained from the Place and Route tool to the design. These files usually are: VHDL file(s) containing a structural model for timing simulation. SDF file(s) containing timing parameters (if SDF generation is supported).
You can also create a separate and new design for files obtained from the Place&Route tool.
74
Creating FPGA and CPLD Designs
Simulating designs after Place-and-Route

The Place-and-Route tools generated VHDL file contains an entity-architecture pair (design entity) describing the design implemented in an FPGA /CPLD device. In general, the entity and architecture in the generated file can have any names. Note that if these names are identical to those of the design units in the initial design description, compilation of the post-Place-and-Route files will cause the same design units to be overwritten in the default design library. It is also important that the ports of the post-Place-and-Route entity match those of the entity in the initial description, otherwise the simulator using the test bench file may not be able to generate proper results.
Performing Timing Simulation (SDF)

To simulate the timing model obtained from the Place&Route tool, you must: Select the entity-architecture pair from the post Place&Route file. Active-HDL automatically seeks the region for which the SDF file is to be loaded.
Checking the automatic region seek option for the SDF file
Creating VHDL Code for Logic Synthesis

When you create a model intended for synthesis, you should have in mind a general notion of its structure. If you do not use this approach, the resulting VHDL code may contain constructs that are not acceptable for synthesis tools. Moreover, if the synthesis of a VHDL model is successful, the results of functional simulation for the netlist in a gate level simulator may differ from the results of VHDL simulation of the initial model. This may result from the fact that: A) Synthesis tools impose specific constraints on the range of available VHDL constructs and contexts in which they can appear. B) Synthesis tools also infer the logic from the context in which specific VHDL constructs appear. Before you begin writing the VHDL code, consult the documentation of the particular tool you are going to use for logic synthesis. Test bench files are intended only for simulation and thus they do not have to comply with the constraints imposed on VHDL syntax by synthesis tools. Each synthesis tool provides packages with functions, procedures and attributes useful in creation of synthesizable models. Particularly, attributes defined in such packages are used to pass specific information to the synthesis tool (e.g. the pin numbers, machine encoding methods, etc.).
75
Application Notes If a design is targeted for an FPGA /CPLD device from a specific vendor, you can use libraries of functional modules and primitives prepared by the vendor. For most vendors, Active-HDL provides libraries in the compiled format. By adding appropriate libraries and use clauses into your VHDL files, you can use modules contained in these libraries. Appendix A contains a list of all vendor-specific libraries shipped with Active-HDL. In addition to libraries of modules, some Place and Route tools also accept parameterized modules. Parameterized modules can be instantiated directly by the user in the VHDL code, or by synthesis tools in the netlist.
76
How to Simulate Designs

Introduction
This chapter describes how to stimulate input signals in the Active-HDL simulator. All examples used in this document are based on the COUNTER sample design which is included with the supplied software. Active-HDL supports the following methods of stimulating or forcing input signals during the simulation: Manually selected stimulators from the Active-HDL resources VHDL Testbench files that have been created by the Testbench Wizard User created created VHDL testbench files VHDL WAVES Test Bench files (as per IEEE WAVES specification 1029.1) Simulation commands entered from the console window Files containing simulation macro commands Test Vector files imported from Active-CAD Simulation input based on waveforms edited by the user
All these methods providing design stimuli can be combined in the same design. You can choose a method which is best suited for your specific design needs and be assured of a good balance between the time required to create simulation input and the complexity of the design verification.
Stimulators
The easiest way to create simulation stimuli is adding the desired signals to the Waveform Editor and assigning stimulators that are available from the Stimulators option. There are several types of stimulators you can choose from. The following stimulator types are supported: Value stimulators allow you to assign a value to the selected signal. The values can be forced on any signals and buses (vectors) and can be applied at any time during simulation. The simulator performs a signal type check to verify that the specified value is allowed for the selected signal type. Formula stimulators allow entering signal waveforms using special formula expressions that can describe asynchronous signals by specifying their transition times and values. For example a formula 0 0, 1 10" describes a waveform that starts with value '0' at time 0 and changes to '1' after 10 simulation units. Hotkey stimulators allow you to control signal values directly from the keyboard. You can select any keyboard key as the hotkey stimulator and assign it to any desired signal. Toggling this hotkey will toggle signal values. For example, if you assign 'R' as a hotkey to the reset signal, then you can toggle the value of the reset signal during the simulation by pressing the R key on your keyboard. Clock stimulators are designed for modeling of clock waveforms. The Active-HDL graphical clock editor allows you to specify clock frequency, duty cycle, etc. Counter stimulators enable defining counters for signals of vector type. Different count radix are available as well as direction and time period for signal changes. Predefined stimulators are clocks with predefined frequency and duty cycle and formulas created by you for the most frequent applications.
77
Application Notes
formulas created by you for the most frequent applications. Custom stimulators are created by assigning graphical waveforms displayed in the Waveform Editor as the simulation input. These waveforms are displayed in the Waveform Editor by using waveform editor, formula or hotkey stimulators.
The Stimulators window Advantages of Stimulators: The quickest and easiest method of forcing signals to the desired states. Interactive assignment of stimulators allows instant viewing of the simulator's response. Stimulators can be applied to any signal and port in the design hierarchy. Handy in debugging low level processes and architectures. VHDL Test Bench can only drive signals at the top design level. Stimulators are saved as waveform files. Stimulators are not sufficient for performing such complex simulations as reading data files, etc.
Disadvantages:
Stimulators are proprietary to Active-HDL and will not work in other VHDL simulators.
Waveform Editor
The Waveform Editor allows you to graphically edit any waveform by using dragging, copying, pasting and drawing new waveform signals. These waveforms can be used as custom stimulators by assigning them to the desired signals. Graphically edited waveforms can also be used as simulation input in conjunction with the Test Bench Wizard, described later in this document, which generates a VHDL test program that is based on the edited waveforms.
78
Sample Simulation Run.
Comparison of Simulation Results

Waveform Editor also allows comparison of the simulation results. Signals for which the difference was detected are displayed in the Waveform Editor window with the red color. The icon enabling the comparison of signals is located in the upper part of the window. The previous simulation run results must be first saved in the project folder. In case of indifferences in simulation runs an appropriate message is displayed.
Comparing simulation runs
Simulation Macros
Macros Entered in the Console Window Active-HDL provides a macro command language for manual entering of such simulation commands as forcing signal values, assigning formulas and executing simulation steps. You can force a value on a signal at any time during simulation by entering the appropriate macro command in the Console window. You can also use macro commands to add forced signals to the Waveform Editor, etc.
The Console window
79
Application Notes Example: Wave creates an empty waveform Wave CE adds CE signal to waveform Wave RESET adds RESET signal to waveform Wave LOAD adds LOAD signal to waveform Wave DIN adds DIN signal to waveform Wave DIR adds DIR signal to waveform Force LOAD 1 0ns, 0 10ns changes LOAD to 1 at 0ns and to 0 at 10ns Force CE 1 changes CE to 1
Files Containing Macros

The simulation macro commands can be executed from a file, saving you time on manual entry of every command in the Console. Simulation macros not only can force input signals but they can also execute other commands in the Active-HDL environment. This allows complete automation of the design verification process, particularly that it can be combined with other simulation entry methods. For example, you can write a script to run a number of simulations using several Test Bench files one after another. Macro scripts can execute external programs such as a synthesis program, batch files, etc. You can also invoke custom commands developed in Script Basic which is included with Active-HDL for automation purposes. Advantages of Macro commands: Fast stimulator entry, directly from keyboard. No need to use GUI windows. Familiar to Model Technology simulator users. Allows automation of the entire simulation process. Proprietary format of the simulation commands. Requires knowledge of the macro language commands.
Disadvantages
The Macro Command File
80
VHDL testbench
The VHDL testbench is a VHDL program that describes simulation inputs in standard VHDL language. There are a variety of VHDL specific functions and language constructs designed to create simulation inputs. You can read the simulation data from a text file, create separate processes driving input ports, and more. The typical way to create a Test Bench is to create an additional VHDL file for the design that treats your actual VHDL design as a component (Unit Under Test) and assigns specific values to this component input ports.
The Testbench Model The VHDL Test Bench can provide simulation inputs and also test the design outputs. For example, you can create a VHDL program that writes design outputs to a text file and compares it against a reference file having the expected values. This methodology provides the most robust design verification with minimum user interaction.
Testbench Created with the Test Bench Wizard

Creating testbenches is a tedious process. The Test Bench Wizard automates this process by guiding you through the process. First, it asks you to select the top level design entity to be tested. Next, you need to enter the name of the waveform file with the desired input and output ports. After answering a few additional questions, the Test Bench wizard gathers the necessary information and creates a template for the test program. You can edit the wizard-generated file; adding your own test scenario and additional inputs, if required.
Test Bench Wizard
81
Application Notes Example: Begin Unit Under Test port map UUT : counter8 port map ( CLK => CLK, RESET => RESET, CE => CE, LOAD => LOAD, DIR => DIR, DIN => DIN, COUNT => COUNT ); end TB_ARCHITECTURE; configuration TESTBENCH_FOR_counter8 of counter8_tb is for TB_ARCHITECTURE for UUT : counter8 use entity work.counter8(COUNTER8_ARCH); end for; end for; end TESTBENCH_FOR_counter8;
VHDL Testbench in IEEE WAVES Format

The Test Bench Wizard allows you to create a template compliant with the IEEE WAVES 1029.1 specification. WAVES is a specification for creating testbench files in the VHDL language. It describes simulation inputs with a specific language implemented as a set of VHDL libraries. It supports verification and testing of hardware designs at any level of abstraction. You do not have to be familiar with the WAVES specification to create these files. If you select this option the Test Bench Wizard will automatically format your testbench program using the WAVES specification. The main benefits of using this format is the ability to format simulation input and output files so that they can be used interchangeably between various simulators. The WAVES format also contains some very useful high level functions for comparing simulation outputs without writing a lot of VHDL code. The standard testbench functions are provided in a compiled WAVES library and allow reading and writing of testbench files in the WAVES format. The difference between the WAVES Test Bench and other testbench files are: It provides a standard file format for waveform data, including formula expressions and stimulator types It has some very useful high level functions for typical testbench operations
VHDL Testbench Created by the User

The VHDL testbench that you create will be treated as one of the VHDL files in the design. You can import existing testbench files and create the new ones from scratch. There are some VHDL packages provided with Active-HDL which include testbench functions. The Language Assistant provides some examples of using simulation specific VHDL constructs. For more information about writing your own simulation testbench please refer to the VHDL literature. Some of the more useful titles are listed at the end of this document. Advantages of Test Benches: This advanced-code simulation input has powerful capabilities Its non proprietary format allows you to run the same simulation on any VHDL simulator. Test Bench can provide simulation inputs and check design outputs at all design stages.
82
How to Simulate Designs Disadvantages: Writing Test Benches is a time consuming process, particularly during the initial design verification. Writing a Test Bench requires good VHDL knowledge
Example: Read cycle for rams with memfiles IF (MEMFILE) THEN FOR i IN 0 TO number_of_iterations LOOP a_bus <= conv_std_logic_vector(i, addr_width); wr_en_pin <= '0'; clock_low(wr_clk_pin); spo_bus_exp := conv_std_logic_vector( conv_integer(a_bus)MOD(2**bus_width),bus_width); clock_high(wr_clk_pin); FOR k IN 0 TO bus_width-1 LOOP IF (spo_bus_exp(k) /= spo_bus_behv(k)) THEN ASSERT FALSE REPORT ERROR: Wrong output while reading mem file. SEVERITY ERROR; exit; END IF; END LOOP; END LOOP; END IF;
Conclusion
As demonstrated in this chapter, Active-HDL provides a variety of methodologies for stimulating designs. For optimal results, use the most appropriate type for each design stage. In the beginning of the design cycle you may want to use interactive stimulators to quickly create simulation inputs and view the design responses instantly. As you develop a better plan for testing your design, you may want to convert the stimulators to a VHDL testbench using the Test Bench Wizard. You can add to it any additional VHDL test functions you may desire. At the end you can add some simulation scripts to automate the verification process and invoke your testbench in the batch mode along with other design tasks such as synthesis, implementation, and comparison of results from different design stages. For more detailed information how to create simulation inputs, please refer to the on-line documentation in Active-HDL.
83
Using Stimulators
Introduction
One of the main advantages of simulation over hardware breadbording is that you dont have to do any logic analyzer setups. All data is automatically captured and analyzed by the simulator, however, you need to apply input signals to the tested model to verify its operation. Signals that you use for circuit simulation are key to effective testing. Some designers prefer to stimulate their designs with signal waveforms, others prefer to use test vectors. For optimal design verification you will probably need both. The Active-HDL tools are derived from more than a decade of comprehensive simulation products from Aldec. Because of this it offers a broad range of stimulator options that have been field tested and proved invaluable in device and system designs.
Available Stimulators
Stimulators are specialized signal waveform generators that can produce any desired legal value on the model inputs. Using stimulators you can easily and quickly define signal patterns that are needed for thorough model verification. They allow you to interactively change any signal value to create the desired testing conditions for the Unit Under Test (UUT). These changes are instant and can be performed during simulation. The simplest way to create simulation inputs is adding the desired ports or signal names to the Waveform Editor and then assigning stimulators to those signals, using the Stimulators option. There are several types of stimulators to choose from: Value Formula Hotkey Clock Counter Custom Predefined
Signal Drivers
85
Application Notes Each stimulator can be forced into being one of the three types: Override - the stimulator overrides the signal value permanently until the next FORCE command. Deposit - the stimulator sets the signal value which remains there until a subsequent driver transaction (e.g. from process P1 or P2) and the associated FORCE command. Drive - attaches a virtual driver to the signal and this driver forces it with the value until the next FORCE command. This type of stimulator is used for resolved signal types only such as std_logic.
Defined Forcing Types Value Value stimulators allow you to assign a permanent value to the selected signal, (e.g. 1, 0). The values can be forced on any signals, buses (vectors) and any port type (in, out, inout, buffered), and can be applied at any time during the simulation. The simulator performs a signal type check to verify that the specified value is allowed for the selected signal type. Values for signals of onedimensional array types can be specified either as character literals or as a based numbers with radix of 2, 8, 10 or 16. Examples: 1011 character literal sequence 2#1011 binary radix 10#11 decimal radix 16#F hexadecimal radix The Stimulator field of the Waveform Editor window (in the figure at the end of this chapter) displays the appropriate signal assignments.
Value Stimulator Formula Formula stimulators define the signal waveform using formula expressions. Formulas can describe asynchronous signals by specifying their transition times and values. Formula expressions use the following syntax: value time [,value time] [-r period] where the -r option allows you to automatically repeat the entered formula after the specified period of time. The default time unit is ps (picosecond). However, you may explicitly assign any one of the following:
86
Using Stimulators ps - picosecond ns - nanosecond us - microsecond ms - millisecond
Examples: 0 0, 1 10, 0 20 defines a logic "1" that starts at 10 (ps) and ends at 20 ps 1 0, 0 5 ns, -r 20 ns defines a pulse wave with period of 20 ns and 25% duty cycle If the entered formula is correct it is assigned and the "formula" word is displayed in the Stimulator field of the Waveform Editor window.
NOTE: The time unit must be separated from the time value by a space.
Formula Stimulator Hotkey Hotkey stimulators allow you to control signal values directly from the keyboard. A hotkey stimulator defines a key that will be used to toggle between values available for the given signal. For example, if you assign a hotkey R to a reset signal, you can then toggle the value of this signal during the simulation by pressing the R key on your keyboard.
Hotkey Stimulator The values available for a given signal depend on its type. The default values are '0' and '1'. You may, however, add additional signal values in the Sequences field of the Simulators/Hotkeys window.
87
Application Notes
Values Available for Hotkeys The Stimulator field displays the keyboard key name that has been assigned to the signal name, which in our example is the "R" keyboard key.
Clock The Clock stimulators are provided for modeling of the clock waveforms. The graphical clock editor allows you to specify clock frequency, duty cycle, initial value and delay. The word Clock is displayed in the Stimulator field, to the right of the clock signal name.
Clock Stimulator
Counter Another powerful stimulator type is the counter stimulator that forces signal values after the specified time periods. You can choose from the available counters modes: binary code Grays code Johnsons code Circular one Circular zero
You need also to specify the counter direction, initial value, in some cases the step of increment, and time period after which the value will be changed. You can also modify the display of the counter in the Waveform Editor window and also change the bits order.
88
Using Stimulators
Counter Stimulator Custom The Custom stimulators allow assigning graphical waveforms displayed in the Waveform Editor window as the simulation inputs. The Custom waveform stimulators can be used only after you have created some waveforms using either the waveform editor, formula or hotkey stimulators. Custom stimulators give you the ability to create very complex waveforms and reuse them as often as required. They combine all the advantages of a Formula and Hotkeys stimulators. The Stimulator field indicates assignment of a custom stimulator with CS letters (Custom Stimulator).
Custom Stimulator Predefined The Predefined stimulators are clocks with predefined frequency and duty cycle or formulas created for frequent reuse.
Predefined Stimulator
89
Application Notes There are eight Predefined clocks which can be altered for the desired frequency and duty cycle. You also have the ability to create any number of your own formulas and assign them to any signal name or port.
User Created Predefined Formula
Conclusion
One of the key issues in design analysis is the use of signal waveforms and test vectors. A signal waveform gives you a better view of the selected signal behavior over time. The test vectors on the other hand give you the exact relationship between signals at any selected time instance. Since Active-HDL allows testing designs both in the test vector and signal waveform domains, everyone will be able to effectively use Active-HDL. It is important to underscore the benefits of using stimulators, they allow you to interactively change the signal values at any point during simulation. Once created, they may be reused as often as desired, saving you time during repetitious verifications of the same design at different design stages. There are such simple stimulators as Hotkeys which are great for simple stimulation, and as complex ones as Formula and Custom which allow you to describe complex and irregular signal patterns (pulse bursts, variable duty cycle clocks, etc.) ideal for verification of complex designs (FPGAs, ASICs, etc). User defined clocks are not necessary in Active-HDL as predefined clock formulas may be assigned to any signal. Another benefit of using stimulators is the flexibility of combining different types of stimulators. It is easier from time to time to create your signal patterns using graphical tools and save them as Custom designs for future simulation purposes. You can see below how different stimulator types look in a sample counter waveform window.
The Waveform Editor Window
90
VHDL Testbench
Introduction
The VHDL testbench is a VHDL program that describes simulation input using standard VHDL language procedures. Simply speaking, the testbench is a top level hierarchical model which instantiates the Unit Under Test (UUT) and drives it with a set of test vectors and compares the generated results with expected responses. A typical VHDL testbench is composed of three main elements: Stimulus Generator; driving the UUT with certain signal conditions (correct and incorrect transactions, minimum and maximum delays, fault conditions, etc.) Unit Under Test (UUT); representing the model undergoing verification. Verifier; automatically checking and reporting any errors encountered during the simulation run. It also compares model responses with the expected results.
The Test Bench Model. To verify and report fault conditions in the most efficient way, Stimulus Generator and Verifier uses textual files which store test vectors and simulation results. With that basis, we can distinguish three testbench configurations.
Off-line Configuration
In this configuration the Stimulus Generator and Verifier take advantage of a file access, and read all needed information (test vectors, expected results) from the previously saved files. The Stimulus Generator reads all input signals from a file and provides clock processes. The Verifier on the other hand compares the UUT responses with the expected results and reports any faulty behavior. VHDL constructs allow logging all responses in a file for documentation purposes and future verification. For example, you can use the same testbench (with the same test vectors files) to verify any changes in a model at different stages of development (logical, pre-layout, P&R) by exchanging the instantiated component.
The Off-line Test Bench Structure.
On-line Configuration
Test Benches also allow you to interactively verify any model changes at different stages of design development. The Stimulus Generator provides the same input signals to each tested model. Thus the response of all models are simultaneously generated and without any user interaction such as exchanging the components. The Verifier operation is much simpler than in 91
Application Notes the off-line configuration, because it only gathers the simulation results from each model and compares them, detecting any differences and deciding whether to continue the simulation or not.
The On-line Test Bench Structure.
Adaptive Configuration
Unlike on-line and off-line configurations, the adaptive testbench configuration requires a good knowledge of VHDL constructs and capabilities. Here, the stimulus generator uses high-level abstraction techniques to adapt test vectors to the changing conditions and responses of a tested model. As a result test vectors are generated in response to feedback from the UUT and Verifier. For example: effective testing models containing such communication protocols as UART or PCI bus. For more information about writing your own simulation testbenches, please refer to the VHDL literature.
The Adaptive Test Bench Structure. Example: architecture TESTBENCH_ARCH of testbench is component GENERATOR is port ( A : in STD_LOGIC; B : in STD_LOGIC; CLOCK : in STD_LOGIC; RESET : in STD_LOGIC; S : in STD_LOGIC; Y : out STD_LOGIC); end component; shared variable end_sim : BOOLEAN := false; signal RESET,Y : STD_LOGIC; signal A,B,S,CLOCK : STD_LOGIC; begin UUT: GENERATOR port map ( A => A, B => B, CLOCK => CLOCK, RESET => RESET, S => S, Y = >Y); CLK_IN: process begin if end_sim = false then 92
VHDL Testbench CLOCK <= '0'; wait for 10 ns; CLOCK <=1'; wait for 10 ns; else wait; end if; end process; S_IN: process begin if end_sim = false then S <='0'; wait for 250 ns; S <='1'; wait for 250 ns; else wait; end if; end process; A_IN: process begin if end_sim = false then A<= '0'; wait for 500 ns; A <='1'; wait for 500 ns; else wait; end if; end process; B_IN: process variable time0 : TIME := 0 us; begin while time0 <20 us loop time0 := time0 + 1000 ns; B <='0'; wait for 1000 ns; B '1'; wait for 1000 ns; end loop; end_sim := true; wait; end process; end TESTBENCH_ARCH; Excerpt from a Generator testbench file to be found in Active-HDL Projects directory.
VHDL Test Bench Wizard

Test Bench files created with the Test Bench Wizard are compliant with the standard VHDL language. The wizard allows creation of a testbench from existing waveforms or creation of a template file where all signal inputs are inserted later. It is sometimes easier to modify a waveform in a graphical editor than to formally describe an irregular pattern. For those who prefer formal methods of forcing signal inputs, the Test Bench Wizard provides a fast and reliable template development environment where all components have been pre-instantiated, saving you time and effort.
93
Application Notes You can invoke the Test Bench Wizard by choosing the Generate Test Bench option from the Tools menu. In the Entity field, select the design for which you want to generate a testbench file and click Next.
The Test Bench Wizard Choose in the next window whether you want to generate a testbench from an existing waveform file or just an empty testbench file for later modifications. In the latter case simply clear the Test vectors from file checkbox and click Next.
The Test Bench Wizard Step 2 The next window allows you to change the name of the testbench entity, architecture and a testbench file. You may also specify the folder where the generated files will be placed.
94
VHDL Testbench
The Test Bench Wizard Step 3 The last window displays the names of the files that will be generated. The first is a testbench file with test vectors. Second is an optional file with timing configuration and the last one is a simulation macro file which automates the entire process of waveform generation, and execution of a testbench file. Click Finish to generate testbench files.
The Test Bench Wizard step 4 Depending on the selected options, the Test Bench Wizard will either create a testbench file with processes driving input signals converted from a waveform or a testbench template file, which allows manual insertion of the desired input signal values.
Summary
The Test Bench wizard automates the tedious process of creating VHDL testbench files. It is sometimes much easier to graphically create the desired waveforms and then reuse them with the same model at different stages of development. Creating a testbench from waveforms is in some cases superior to formal description of irregular patterns, and its a great time saver.
95
Application Notes
VHDL Test Bench In IEEE WAVES format

The Test Bench Wizard allows you to create templates compliant with the IEEE WAVES 1029.1 specification. WAVES is a specification for creating testbenches in the VHDL language. It describes simulation input using specific language constructs implemented as a set of VHDL libraries. It supports verification and testing of hardware designs at any level of abstraction. The WAVES testbench file is a sequential program that when executed generates a waveform for all signals that are described in a testbench file. These waveforms define the sequence of events (timing, logic, value, and direction) for signals during a test. The WAVES testbench in context of a VHDL simulation is simply one or more concurrent process. A WAVES testbench file is comprised of two or more WAVES files, optional external files and a header file. The header file contains information about the testbench configuration and construction. The WAVES testbench requires a number of information pieces to fully specify a testbench file. These include the names associated with each of the UUT pins, logic values and their timing. You need to make the following declarations: Logic value - defines all of the legal values that the signal of the waveform may exhibit. The sequence of signal logic values creates the waveform shape. Logic vector - is a composite type that gathers all of the signals of the generated waveform within one object. Pin codes - is a string constant that defines the legal characters that may appear in pin code strings that are applied to the signal waveforms. These characters may represent one event or sequences of events on a signal. Maximum frame events - is a constant named max_frame_events that constrains data structures in the WAVES standard package WAVES INTERFACE. Frames and frame sets - is a sequence of zero or more events and a direction specifier. These events are logic value-time pairs. Frames aggregate events into waveform segments or shapes and define direction of the events within a frame. Similar frames may be grouped together into frame sets. The number of elements in a frame set is given by the number of characters in the pin code string declaration. Test pins - contain one enumeration value for each pin specified by the test set. The identifiers enumerated here represent names of the signals of the UUT. The order of the declaration defines the order of the waveform signals. Waveform generator procedure (WGP) - declares the interfaces between the WAVES testbench and its environment. By using information defined in other declarations, standard packages, and optional external files, the WGP completely describes the construction of the waveform.
A WAVES testbench also provides interfaces which allow synchronization with events occurring in tested environment. There are two mechanisms called match and handshake. This is similar to the adaptive configuration of a normal testbench file.
96
VHDL Testbench Example: ARCHITECTURE counter_test OF test_bench IS -- CONFIGURATION SPECIFICATION COMPONENT counter PORT ( clk : IN std_ulogic; Data_out : OUT std_ulogic_vector( 0 to 3 )); END COMPONENT; FOR ALL:counter USE ENTITY work.counter(behavioral); -- stimulus signals for the waveforms mapped into UUT -- INPUTS SIGNAL clock :std_ulogic := '1'; - Expected signals used in monitoring the UUT -- OUTPUTS SIGNAL WAV_EXPECT_Data_out :std_ulogic_vector( 0 to 3 ); - UUT Output signals used In Monitoring ACTUAL -- Values SIGNAL ACTUAL_Data_out :std_ulogic_vector( 0 to 3 ); - WAVES signals OUTPUTing each slice of the waves -- port list SIGNAL wpl : WAVES_port_list; SIGNAL wmr : WAVES_match_request; SIGNAL MATCH_ACK : WAVES_MATCH_ACK; SIGNAL WHR : WAVES_HANDSHAKE_REQUEST; SIGNAL HNDSHK_ACK : WAVES_HANDSHAKE_ACK; BEGIN - process that generates the WAVES waveform WAVES: waveform(wpl, wmr, match_ack, whr, hndshk_ack); - processes that convert the WPL values to 1164 -- Logic Values clock <= not clock after 10 ns when NOW=1us else '0'; WAV_EXPECT_Data_out wpl.signals( 2 to 5 ); - UUT Port Map - Name Semantics Denote Usage ul:counter PORT MAP( Clk = clock, Data_out = ACTUAL_Data_out); - Monitor Processes To Verify The UUT Operational -- Response Monitor_Data_out : PROCESS(ACTUAL_Data_out, WAV_expect_Data_out) BEGIN if MATCH_ACK = TRUE then assert Compatible (actual =ACTUAL_Data_out,expected = WAV_expect_Data_out ) report Error on Data_out output severity WARNING; end if; END PROCESS; Handshake : Process begin wait until WHR.REQUEST'transaction'event; if WHR.REQUEST = TRUE then HNDSHK_ACK TRUE; wait until clock'event and clock = WHR.VALUE; HNDSHK_ACK FALSE; end if; end process; Match_Data_out : process variable RESULT : Boolean; begin
97
Application Notes wait until WMR.REQUEST'event and WMR.REQUEST = TRUE; MATCH_ACK FALSE; RESULT := TRUE; wait for WMR.SAMPLE; for I in WAV_EXPECT_Data_out'range loop RESULT := RESULT and ACTUAL_Data_out(I) = WAV_EXPECT_Data_out(I); end loop; MATCH_ACK<= RESULT; end process; END counter_test;
Summary
You do not have to be familiar with the WAVES specification, to create these files. The Test Bench Wizard automatically formats your testbench program using the WAVES specification if you select this option. The main benefits of using this format is the ability to format simulation input and output files so that they can be interchanged between different simulators. The WAVES format also contains some very useful high level functions to compare simulation outputs without writing extensive code in VHDL. The standard testbench functions are provided in a compiled WAVES library and allow reading and writing of testbench files in the WAVES format. As compared to other testbench files, the WAVES testbench provides: Standard file format for waveform data including formula expressions plus stimulator types. Higher level functions for typical testbench operations.
Conclusion
The Main advantage of testbench files is that they automate design verification. They allow fast and accurate verification that the UUT responses are as expected and the UUT interface protocols meet their specifications. Manual verification through visual inspection of waveforms is inefficient and prone to errors. Because of the VHDL language capabilities, testbench files are powerful tools for interacting with tested models where stimulators are not efficient enough to keep up with changing conditions. Another advantage of using testbench files instead of test vectors is portability between different simulation tools. A file written in a VHDL language is compatible with any VHDL compliant simulator. Thus the same testbench architecture can be reused and shared on many vendorindependent platforms. However, a thorough knowledge of VHDL language is required to get the best results. It may be sometimes easier to use simple stimulators or test vectors, as the design size may not necessitate complex testbench files. Furthermore, writing a testbench file is a time consuming process and is not recommended for situations where only initial verification is needed. In that case simple test vectors may be sufficient.
98
Glitches and Delta Cycle Handling

Introduction
This chapter describes how Active-HDL handles glitches and delta cycles. The purpose of this document is to familiarize you with the terminology, basic simulation procedure and means for finding causes of glitches. Active-HDL provides you with handy graphical tools that simplify the design verification process. The Design Browser windows allows quick design review and simplifies locating instances that cause the design misbehavior.
Delta Time
One of the requirements of simulation is execution order independence for each of the concurrent statements. Thus if a signal X is inverted by process "A" from '0' to '1' and the signal X value is read by the process "B" at the same time, it is important that process "B" reads the old and not the inverted value of '0', regardless of the process execution order. See the VHDL code below. To achieve this goal, the simulator tags each signal for an update when all current processes have been completed for the current time period. This time is called Delta Time. A delta time is an infinitesimally small amount of time that represents a time greater then zero, but it is zero when added to a discrete amount of time. Thus if a signal assignment is made at time "100ns + 1 delta time" and the model discrete delay is 10ns, the new signal value is assigned at 100ns + 10ns + 0 delta time = 110ns. This is because the 1 delta time * 1 = 0ns. The VHDL code for our example: signal X : std_logic := '0'; signal Y : std_logic; A: process begin wait for 100 ns; X <= not X; end process; B: process (X) begin Y <= X after 10 ns; end process;
The Simulation Results. Active-HDL has a List window that allows displaying signal values with the corresponding time events. The List window has two default columns: Time - displaying signal event time Delta - displaying the number of delta times for current delta cycle
All signal values are presented in text format and each signal has its own column. You can add signals to the List window by dragging them from the Design Browser window or clicking the Add signals icon on the toolbar. Any signal changes during the simulation run are automatically
99
Application Notes updated in the List window. You can add or remove signals from the List window while the simulation is in progress. By clicking the Collapse delta icon you can toggle delta cycles display for the current time.
The List Window
Glitches
Since propagation of electrical signals through actual device takes some time, the actual device and circuit behavior may be quite different from the one expected, based on the functional simulation. Actual devices have a number of restrictions on their input signals. For example, if the input signals change much faster than the device can respond, the responses may not be as expected. Glitch is a short pulse on the signal waveform, that is usually undesired and may cause an unexpected design behavior. When a simulator produces output signal waveforms for no reason, you may enable the display of glitch warnings in the Design/Settings window. To see the glitches on the display, your design project library must contain design units with described unit delays or the project should include a file with timing descriptions for devices used in the design. A file is created after the placement and routing process. This file contains a netlist of the design after the netlist file is fitted into the vendor-specific part. It is usually written in the Standard Delay Format and has the SDF extension. To better understand glitches and their influence on the design behavior we will now review an example from the Active-HDL Projects directory. For this purpose we will use the Xilinx_Counter project. Entering the Xilinx_Counter design you will create a simple 4-bits synchronous counter with asynchronous reset. The target device for the design will be 4003EPC84-4. First, you have to open the project using the Project Explorer invoked from the File menu. If you are not familiar with the design management please see the Design Management Features in Active-HDL chapter. In the Design Browser window navigate to the Implement folder and execute the Implement.Do macro file. This will invoke the Active-Synthesis software that creates the netlist file for the Xilinx_Counter design. Next, the same macro file will automatically launch the Xilinx place and route tools that will map and fit your netlist files into the desired Xilinx part. For those users who do not have the Xilinx software, all necessary timing specification files are included in the Timing subdirectory. These files have been generated by the Xilinx place and route tools and have been provided here for your convenience. To run the timing simulation you need to execute the run_timing.do macro file that creates the new Waveform Viewer window and performs the simulation process. Below you will find the contents of the run_timing.do macro file:
100
Savealltabs quiet on vcom counter_tim.vhd vcom counter_TB.vhd vcom timing_cfg.vhd vsim -sdfmin \UUT=$DSN\src\timing\counter_tim.sdf TIMING_FOR_counter wave CLK wave RESET wave Q run -all endsim quiet off During the simulation you should observe the warning messages displayed in the Console window. An example of a warning is presented next: WARNING: VitalGlitch: GLITCH Detected on port O ; Preempted Future Value := 0 @ 261.714 ns; Newly Scheduled Value := 1 @ 261.749 ns; Time: 259049 ps, Iteration: 2, Instance: \UUT\Q_2_INT_FGBLOCK_LUTRAM_GLUT_OR2. Active-HDL allows you to disable glitch detection by checking the Ignore VITAL glitches option in the Simulation tab of the Design Settings window.
The Design Settings Window The VITAL glitch detection mechanism displays glitch warnings. According to the VITAL specification a glitch occurs when a new transaction is scheduled to occur at an absolute time that is grater than the absolute time of a previously scheduled pending event. Glitch handling in a VITAL model is incorporated into the signal scheduling mechanism. In the Xilinx_Counter example the Waveform Viewer does not display glitches, because of the VitalInertial transport delay mode. To better understand the transport modes and the simulation behavior that they cause we should consider the figure below, that displays the buffer behavior.
101
Application Notes
Transport Delay Types The first two transport delays VitalInertial and VitalTransport are identical to inertial and transport VHDL modes. The OnEvent and OnDetect modes are especially useful for glitch handling. In the OnEvent mode the glitch causes an 'X' value to be scheduled on the output at the time when the event was to occur. As you can see in the figure above the glitch is displayed after the Delay time from the moment the glitch started. In the OnDetect mode, a glitch causes the 'X' value to be scheduled on the output at the time of glitch detection. As seen in the figure above the 'X' value is forced on the output for the Delay time from the moment that glitch detection mechanism detected the signal glitch. In our example the glitch has been detected on the output O port of the \UUT\Q_0_INT_FGBLOCK_LUTRAM_GLUT_OR2 instance. To find out why it is not displayed in the Waveform Viewer window, check if it is not caused by the unit transport delays. To quickly locate the listed instance, use the Design Browser window. Select the Structure tab and expand the hierarchy structure. At first you will only see the top level hierarchy of your design. Active-HDL displays two kinds of icons within the design structure. The rectangular icons represent blocks resulting from the design elaboration and the circular ones represent concurrent processes. As you can see from the figure below, the top-level hierarchy is timing configuration for the counter. In the hierarchy tree there are two branches: UUT:counter - the unit under test containing all design components Stimulus - the active stimulus process
The Design Structure Next, you should expand the block named UUT (Unit Under Test) : Counter to see the design components. You need to locate the Q_0_INT_FGBLOCK_LUTRAM_GLUT_OR2 gate. By clicking on it, the Design Browser displays additional information in the lower part of the window.
102
Timing Specifications in the Design Browser Window What interests us the most is the lower part of the Design Browser window. As you can see above, there are four time structures of the VitalDelayType01 type. Each of these structures contains two time values: first, containing the time for signal transition from 0 to 1 second, containing the time for signal transition from 1 to 0
The tipd_I1_O and tipd_I0_O structures hold time values for the input delays. This is the time after which a signal change is propagated from the input to the circuit. The tpd_I1_O and tpd_I0_O structures hold time values for the output delays. This is the time after which signal change is propagated through the circuit to the output.
The Input and Output Delays of the OR Gate The tpd time values for the Q_0_INT_FGBLOCK_LUTRAM_GLUT_OR2 gate (figure above) are 2700ps and the tipd values are 0ps. Therefore there is no input delay, which means that signal changes are instantly propagated to the circuit. A default time unit for each component is inserted into the SDF file and in this example it is picosecond - ps.
103
Application Notes Keeping in mind all the above information, we can now explain what causes the glitch. In the warning displayed in the Console window the time of the glitch detection is 259049 ps (259.049 ns). This is specified in the line beginning with the Time: clause: WARNING: VitalGlitch: GLITCH Detected on port O ; Preempted Future Value := 0 @ 261.714 ns; Newly Scheduled Value := 1 @ 261.749 ns; Time: 259049 ps, Iteration: 2, Instance: \UUT\Q_2_INT_FGBLOCK_LUTRAM_GLUT_OR2. The next preempted value for the output O port is '0' at 261.714 ns. However, the newly scheduled value for the output O port is '1' at 261.749 ns. We should keep in mind that the current output value for the O port is '1'. The absolute time period between those two transactions equals 35ps and we know that the output delay for this particular gate is 2700ps. If we add the present time value of 259049ps and the output delay of 2700ps then we will have the result of 261749ps. This is the time of newly scheduled value for the output O port.
Output Signal with Glitch The value of this port will not change on the display because of the inertial delay type specified for our design, which does not transport any signal changes having time duration smaller then the output delay tpd. However, because the project is compliant with the VITAL standard, the glitch detection mechanism will generate the glitch warning. This is due to the short spike on the output signal for the port O with time duration of 35ps. The cause of the glitch can be easily explained. As you can see in the above figure, the I1 signal changes from '1' to '0' at the 259.014ns and the I0 signal changes from '0' to '1' at the 259.049ns. The time period between those two events is exactly 35ps. Those transitions on the inputs of the OR gate should cause at first a short change on the output from '1' to '0', and after 35ps from '0' to '1'. However, the design operates in the VitalInertial transport mode where all input changes that have duration time shorter than the output delay tpd are not propagated to the output and no glitch will appear at the output. The simulator therefore does not display the glitch on the waveform, however, generates the warning that the glitch has been detected. Consequently all glitch warnings can be explained this way.
Conclusion
The timing simulation is used to verify that a circuit will operate properly under the worst-case of propagation delays and input signal conditions. Since the actual propagation delays are known after the device have been laid out, the Active-HDL simulator allows to include the timing specifications, contained in the SDF file, for accurate verification of the design. Functional
104
Glitches and Delta Cycle Handling simulation allows you to verify functional behavior of the tested model. However, it is the timing simulation that verifies proper design operation under any timing conditions. Active-HDL takes advantages of the VITAL specifications and mechanisms for glitch detection and allows you to verify the design operation under the worst-case propagation conditions. In most cases the glitch is caused by input signal transitions with too short time duration. As shown in this chapter, Active-HDL allows you to quickly locate and verify the timing specifications for any instance by clicking on their corresponding icons in the Design Browser window. At first, the glitch information may seem incomprehensible but with a little experience it is easy to read and understand. Active-HDL allows testing designs step-by-step. You may even follow the simulation changes with the delta precision. By switching to the List window and enabling the Delta time mode, you can view signal changes for each simulation cycle.
105
VHDL Debugging
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 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 code: Syntax Checking - performed with the every Compile command. Code tracing - VHDL 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 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 VHDL 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
107
Application Notes The Compile command automatically checks the VHDL source code for compliance with VHDL 93 LRM. There is, however, an option for checking compliance with the VHDL 87 LRM code syntax. 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. 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 VHDL code or State machine. 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 Active-HDL allows checking the State Machine generated VHDL code for errors. In the same window you can select one of the two options: trace the original state machine trace VHDL 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 chapter: Waveform Editor Features. Active-HDL provides an interactive graphical environment for design development and verification. When necessary, you can trace the VHDL source code statement-by-statement. There are four functions that allow you to trace the code: Trace into - executes a single VHDL statement. If a subprogram call is encountered, the execution descends into the subprogram body. Trace over - executes a single VHDL command. If a subprogram call is encountered, the statements contained within the subprogram body are executed in a single step.
108
Building VHPI Applications
Trace out - executes as many VHDL statements as are 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 VHDL statements as are 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, highlighting in yellow the currently active state. 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 VHDL code and observe its influence on the models behavior.
The State Machine Editor
Breakpoints
Another useful feature of Active-HDL is its ability to insert breakpoints into VHDL 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 VHDL Editor allows inserting breakpoints only in the lines where appropriate, for example: statements containing assignment expressions, etc.
Simulation Breakpoint
109
Application Notes 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 breakpoints 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 generated for the signal or it is forced by the simulator 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 VHDL models code that will help you to verify the designs 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 which can be displayed not only in the Waveform Editor but in additional 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.
110
The List Window.
Watch Window
To find the last value or current signals 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
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 VHDL 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 Process Window
111
Application Notes 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. 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.
The Processes window can show either:
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
Data Flow Window

The Data Flow window is a tool providing a graphical view of signals flowing in and out of processes during simulation. The term process is used here to mean any concurrent statement
112
Building VHPI Applications 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). The window provides two different views: with a process in the center of the window, with a signal in the center of the window.
When a process is displayed in the center, it is represented as a rectangular box with input signals on the left side and output signals on the right. Input signals are those read by the process and output signals are those updated by the process.
Data Flow Window - 1 When a signal is displayed in the center, it is represented as a vertical thick line with processes connected to it on both sides. Processes on the left side update the signal. Processes on the right side read the signal. You can switch between these two views by clicking items in the Dataflow window.
Data Flow Window - 2 In both views, signals are displayed with their names and processes are displayed with their labels (either assigned explicitly by the user or generated automatically by the simulator). For signals, the Dataflow window also displays their current values.
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.
113
Application Notes 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 VHDL 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 VHDL 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 VHDL code to stop the simulation when the specified code line is entered. Finally since the Active-HDL environment is interactive, you can execute the debug functions while the simulation is in progress.
114
Building and Debugging Handel-C Projects

Introduction
Active-HDL, except features dedicated to verification of HDL designs, also provides an advanced built-in debugging tool that allows you to debug simulation models based-on the Handel-C language. The option is a feature that allows you to debug in the Active-HDL environment. The Handel-C Code Debug option provides extended verification capabilities for debugging Handel-C source code and DLL libraries built in the Celoxica DK Design Suite environment.
NOTES: 1. In order to use the Handel-C Code Debug option, this feature must be enabled in your license. 2. This feature is not included in the vendor-specific editions of Active-HDL.
The Handel-C Code Debug option requires: Active-HDL 6.1 SP2 or higher Library containing a source code to debug must be built by using Celoxica DK Design Suite 2.0 SP2 or higher. The compiler must build a library with debug information enabled. See the Compiler tab of the Project Settings dialog box in the on-line documentation for additional information (Active-HDL Help | Dialog Box Reference).
This application note will help you get familiar with creating and importing Handel-C projects and show you how to debug them in Active-HDL. In this application note, we will import the Celoxica's sample project Example1. The sample describes an accumulator that reads data and writes results to a file. It is stored in the <DK_directory>\Examples\Handel-C\Example1\ subdirectory.
Creating new design

1. Start Active-HDL by opening the Start | Programs group and clicking the Active-HDL icon. The Active-HDL Welcome screen appears and then the Getting Started dialog opens. 2. Select the Create new workspace option and click the OK button. You can alternatively use the File | New | Workspace option to open the New Workspace window. 3. The New Workspace Wizard appears. In the wizard's dialog, you can enter the name and location of the workspace. Enter acc in the Type the workspace name field. Make sure that the Add New Design to Workspace checkbox is selected. 4. Click the OK button. After the New Workspace Wizard window has closed, the New Design Wizard dialog box appears. 5. Select Create an empty design in the New Design Wizard window and press Next. In the dialog box where synthesis and implementation tools are set, click Next. 6. Enter a new design name acc in the Type the design name filed. 7. Finish creating the empty design by clicking Next and then the Finish button. The new acc workspace/design is created in the C:\My_Designs\ directory and displayed in the Design Browser window as it is shown in the figure below.
115
Application Notes
Importing Handel-C Project

8. Open the File | Import menu and choose the Celoxica DK Project option. The Select Celoxica DK Project window opens. Go to the \Examples\Handel-C\Example1\ subdirectory of the DK installation directory and choose the Example1.hp Handel-C project file.
9. Click Open, which imports the entire Handel-C project into the Celoxica subfolder. After the Handel-C project has been attached, the new project folder (the name of the subfolder is inherited from the name of the *.hp file) is created and it contains links to the original Handel-C source files of the imported project. The imported project is presented in the figure below.
116
NOTE: If required, you can create a new Handel-C project from scratch. To do so, open the File | New menu and choose the Handel-C Project option that runs the New Handel-C Project Wizard. After the project file (*.hp) is attached to the design, you can add new source files and modify appropriate settings in the Project Settings dialog box. See item #10 below or the on-line documentation for more information on changing project settings.
Specifying Project Settings

10. After the project has been imported, you can specify settings for the compiler, linker, debugger, paths to additional objects or libraries, etc. This can be done by using the Project Settings option. To open the Project Settings dialog box, right-click the Example1.hp file and choose the Handel-C Project Settings option from the pop-up menu. As it was mentioned above, sum.hcc describes the Handel-C model that reads data from a text file. The sum_in.dat file is stored in the <DK_directory>\Examples\Handel-C\Example1\ subdirectory. The file and information on its location is used while building the Handel-C project and initializing the debugging session. The newly created acc sample design is stored in the C:\My_Designs\acc subdirectory. Thus, to avoid errors, you should specify the path to the sum_in.dat file before you compile the project. Otherwise, you may encounter the read out problem and you will see the following message in the Console window: # Handel-C Code Debug: Could not open input file 'sum_in.dat' In this example you can solve this issue by modifying the source code or specifying a working folder for the debugger.
11. To specify the settings for the debugger, click the Debugger tab and enter the path to subfolder where the sum_in.dat file is stored. Setting the path to the working folder of the debugger is equivalent to the specification of the absolute path to the sum_in.dat file in the Handel-C source code. 12. If you want to modify it, double-click the sum.hcc source file, which opens the HDL Editor window. Then, find and replace the following lines of the code: chanin input with { infile = "sum_in.dat" };
117
Application Notes chanout output with { outfile = "sum_out.dat" }; with (provided that the DK software was installed with the default installation path and the acc design was created in the above specified directory): chanin input with { infile = "C:/Program Files/Celoxica/DK/Examples/Handel-C/Example1/sum_in.dat" }; chanout output with { outfile = "C:/Program Files/Celoxica/DK/Examples/Handel-C/Example1/sum_out.dat" }; This change allows your imported Handel-C model to read data from and save them to the specified location without the necessity to copy the sum_in.dat file after importing the project into Active-HDL. Otherwise 13. Save the changes and compile the source code. To build the Handel-C project, right-click the Example1.hp Handel-C project file and choose the Build Handel-C Project option or type in the following command to the Console window: buildc example1.hp The compilation results are displayed in the Console window.
After the compilation, you should specify the Handel-C library to be debugged (this library is also used while co-simulating HDL units and Handel-C models). This information can be entered either in GUI or by using an environment variable. 14. If you want to set it by using GUI, open the Design menu and choose the C/Handel-C Code Debug Settings option. It opens the dialog box that allows you to specify debugging settings for either C/C++ or Handel-C applications. 15. Open the Handel-C Code Debug and Co-simulation Settings tab. 16. Enter manually the path to the Example1.dll library in the Select Handel-C Library for Debugging and Co-simulation field or use the Browse button to find the library. 17. Click OK to close the dialog box. By default, after you have successfully compiled the Handel-C project, the path to the library is set automatically. If the path is not set or you change it, pressing OK or Apply will save the change and the Console window will display the current location of the library: # set HANDELC_SIMULATOR C:\Program Files\Celoxica\DK\Examples\HandelC\Example1\Debug\Example1.dll
118
18. If you want to use the environment variable, you need to specify the value of the HANDELC_SIMULATOR variable. To do so, issue the following command in the Console window: set HANDELC_SIMULATOR "C:\Program Files\Celoxica\DK\Examples\HandelC\Example1\Debug\Example1.dll" Issuing the command sets the path in the Select Handel-C Library for Debugging and Cosimulation field too. Now, the Handel-C project is ready to debug and you can initialize the debugging session.
Debugging Handel-C Project

19. Open the Simulation menu and choose the Initialize Handel-C Code or type the following command in the Console window: hcdebug $HANDELC_SIMULATOR The Console window reports the status of the Handel-C debugger displaying the following message: # Handel-C Code Debug: Initialized and the sum.hcc file is loaded to the HDL Editor window. The yellow debug line is visible in the window, which means that you proceed to debug the Handel-C source code. 119
Application Notes Before you start tracing the code, you need to add variables to watch and, if you want to save the results to a waveform file, select objects to be traced. The built-in debugger provides the HandelC Code Debug window that allows you observe objects of the debugged model. To open this window, choose Handel-C Code Debug from the View menu or press Alt+F9. The Source tab displays all (re)sources files compiled into the library
The Clock/Thread tab displays information on the clocks declared in the project, threads in operation during debug, the current number of clock cycles, and the current location of the debug line in the source code.
The Call Stack tab lists the functions and macro procedures called on the way to the current function. The current function or macro procedure appears at the top of the list, followed by those that have not yet completed.
The Watch tab shows program's variables. 20. To add a variable, click the Watch tab. 21. Double-click an empty row in the Expression column (or select it and press F2). This turns the editing mode on and you can enter the name of the item you want to observe e.g. sum. 22. Press Enter to complete. You can also add variables directly from the source code displayed in the HDL Editor window.
120
23. Select the name of the variable and right-click the selection. 24. Choose the Add to Handel-C Code Debug Watch option from the pop-up menu. This operation is reported to the Console window: # Handel-C Code Debug: Variable added to watch - "data" Depending on the visibility scope i.e. the function being currently debugged, you may see <Unavailable> displayed in the Value column. Additionally, while entering the name manually, pay attention to the proper use of the character case since identifier names are case sensitive. Now, you should see two variable added to the Watch tab as it is shown in the figure below.
The next step is to select objects to be traced during debug and saved to the waveform file. 25. Click the Variables tab. 26. Check the variables you want to trace and save to the waveform file. 27. In the Step time field, enter 100ns. The value specified in this field is the time of the execution of subsequent lines of the source code during debug. This parameter is equivalent to the time step required to execute one line of the source code, which also allows a graphical representation of debugging results on the waveform. The name of the wavefom file is displayed in the Waveform path field and can be changed (manually or by using the Browse button) only before the initialization of the debugger. After the initialization, both fields are unavailable.
121
Application Notes
Now, you can start debugging the source code. The integrated Handel-C debugger allows using the Active-HDL Trace In , Trace Over , or Trace Out Each step of the debugger is reported to the Console window. options from the main toolbar.
You can also set breakpoints while debugging the Handel-C code. 28. To do so, press F9 or choose Toggle Breakpoint from the Simulation menu. Setting breakpoint will be reported in the Console window. The list of breakpoints that have been set is available in the Edit Breakpoints window (Simulation | Edit Breakpoints).
After several steps, you can see the new values of the variables on the Watch tab.
The sum_in.dat file stores data read during debug. When the debugger reads data=0 then it executes the last line of the code and the debugging session is closed. Obviously after you have reached the end of the debugging process, you may finish the session at any time. 29. To close the debugging session, choose End Simulation from the Simulation menu or type in the endsim command in the Console window. When the session is closed, you can open the waveform file and verify the results. The waveform window is presented in the figure below.
122
The debug session ends at 11th cycle. As it was mentioned above, each change occurs after 100ns, which is equivalent to the execution of one line of the source code. On the waveform presented above, you can see that the first read out of data is at 100ns, then the value is processed by the accumulator and written to the output at 200ns. At 300ns the read out cycle stats again but the new value is added to 1 (stored in the accumulator) and at 400ns written to output. These operations are repeated until 0 is encountered in the sum_in.dat file. The value stored in the accumulator in the last cycle of debug is written to the sum_out.dat file after the session is finished.
123
Co-simulation of Handel-C Projects in Active-HDL

Introduction
Handel-C projects that have been attached to Active-HDL can be verified by using its native simulation environment and built-in debugging tools. You can not only build and debug a HandelC source code, but also instantiate a Handel-C-based model within an HDL design and cosimulate such a mixed-language project. Active-HDL provides a built-in co-simulation interface that allows you to co-simulate Handel-C models with both VHDL and Verilog units. The built-in interface allows you to: Use Active-HDL to initialize the co-simulation process if the HDL unit is top-level instantiating a Handel-C block. If the HDL block is instantiated in Handel-C then ActiveHDL plays the role of the co-simulator. Observe co-simulation results in the Active-HDL Waveform Viewer Debug Handel-C code in the Active-HDL HDL Editor Watch Handel-C variables in the Handel-C Code Debug window
NOTES: 1. In order to run co-simulation in Active-HDL, it must be enabled in the license file. 2. This feature is not included in the vendor-specific editions of Active-HDL. See the on-line documentation for details.
This application note will present how to prepare and co-simulate both models (HDL and HandelC) and carry out the co-simulation process in Active-HDL. As an example, we will use the acc sample design that is described in details in the Building and Debugging Handel-C Projects application note. That document presents how to create or import a Handel-C project into ActiveHDL, then build it and debug the simulation library.
Requirements
To run co-simulation, the interface requires the following tools to be installed: Active-HDL 6.1 SP2 or higher Celoxica DK Design Suite 2.0 SP2 Celoxica Platform Developer's Kit 2.1 Project-specific wrappers that will connect inputs and outputs of your HDL unit to a Handel-C model Handel-C code with a definition of a "simulation interface" that will allow ports of the Handel-C model to be accessed by the HDL simulator HDL/Handel-C co-simulation plug-in
Additionally, before you start simulating any design, you will need:
125
Application Notes
Preparing Handel-C Source File for Co-simulation

In this example, we will instantiate a Handel-C model within an HDL unit, which means that Active-HDL will play the role of the master simulator. First, we will present how to create an interface that allows ports of the Handel-C model to be accessed by Active-HDL. 1. Load the acc sample design. This example has been described in the Building and Debugging Handel-C Projects application note.
2. Open the sum.hcc source file. The original interface of the accumulator coming from the DK's Handel-C sample project uses input and output channels that read and write data to the files (sum_in.dat, sum_out.dat). In this application note, we will replace the channels with a simulation interface that can be accessed through input and output ports during simulation by Active-HDL. 3. Replace the original description of the accumulator with the following source code:
The simulation interface for the acc model defines the Handel-C interface sort (_acc), input (data_in) and output (data_out) ports of the accumulator, and the specification of the interface used for co-simulation. The with construct points to: co-simulation plug-in (extlib = "AldecHandelC.dll") The $PATH system variable must point to the $ALDEC\Bin subdirectory of the ActiveHDL installation. Otherwise, you need to specify the absolute path to the DLL file. co-simulated model (extinst = "modelname=wrapper; delay=100000") extinst defines arguments that are passed to the simulator. It provides information on
126
VHDL Debugging the name of the co-simulated HDL unit (modelname=wrapper) and the "sampling unit" for a combinatorial logic (delay=<delay_value>). <delay_value> is as a positive integer value expressed without the base unit. The delay time after which data is synchronized is a result of multiplication <delay_value> by the current simulation resolution. The syntax of the extinst specification is dependent on your HDL design unit. If the HDL unit represents a sequential logic, the Clock signal should be specified (clock=<clock_name>). It synchronizes both simulators and data exchange on the rising edge. If the HDL unit represents a combinatorial logic then the clock parameter can be omitted. Otherwise, it is required and delay can be skipped. NOTE: Refer to the Interface definition and Handel-C interface for co-simulation chapters in the Handel-C Reference Manual and the Platform Developer's Kit documentation, respectively for detailed information on the Handel-C Interface specification. For additional information on co-simulation, refer to the Active-HDL on-line documentation.
In the body of the main() function, the sum_out variable has been added. It passes the value of the internal variable sum to the output port of the accumulator (data_out). In the original Handel-C model, this variable read data stored in the sum_in.dat file. In the modified code, the read out of data from the file has been replaced by the specification of the input port (data_in). 4. Save the changes to sum.hcc. 5. Right-click the Example1.hp project file and choose the Build Handel-C Project option from the pop-up menu.
Preparing HDL Source Files for Co-simulation

After the Handel-C model has been re-built, you need to create an HDL wrapper for the Handel-C model that will be instantiated in an HDL design. A wrapper file will pass values of inputs and outputs between a VHDL or Verilog unit and the co-simulated Handel-C model. You can create either a VHDL or Verilog wrapper. To create the wrapper: 6. Add a new HDL source file (File | New VHDL/Verilog Source) or run the New Source File Wizard. If you want to use a VHDL wrapper, you will need to define a communication interface based on VHPI. If you prefer Verilog, you will need to create an interface based on PLI. The VHDL wrapper communicates with the Handel-C model by using a foreign architecture and the built-in VHPI interface. In this method, the entity of the wrapper contains additional declarations of constants that specify parameters for the communication interface required to bind the Handel-C model with the HDL design. These constants are required (they cannot be renamed) to pass two parameters to the simulator: the name of the library (*.dll) containing compiled Handel-C model (HANDELC_SIMULATOR) and the name of the VHDL wrapper for this model (MODELNAME), respectively. The value of both variables can be set by using the set macro command or specified on the Handel-C Code Debug and Co-simulation Settings tab of the C/Handel-C Code Debug Settings window.
NOTES: 1. The names of ports declared in the wrapper's entity must match the names of ports of the Handel-C model. 2. It is recommended to use the STD_LOGIC, STD_LOGIC_VECTOR, SIGNED, or UNSIGNED type for the ports of the wrapper. If the unit uses other types, you will need to create another VHDL wrapper containing type conversions to the listed types.
127
Application Notes
The attribute foreign declared in the handelc architecture indicates that the wrapper has a VHPIbased implementation and specifies the VHPI interface that will be used during co-simulation. AldecHandelC.dll points to the co-simulation plug-in. This file is delivered along with Active-HDL and it is stored in the $ALDEC\Bin subdirectory. The system variable $PATH must point to this subdirectory. Otherwise, you will need to specify the absolute path to the DLL file. cosim_handelc identifies a VHPI-based implementation for a foreign architecture. See the VHPI Reference Guide or the Active-HDL Interfaces and Application Notes chapters for more information on the built-in VHPI interface. The example of the VHDL wrapper is presented below.
The Verilog wrapper communicates with the Handel-C model by using the PLI interface. In this method, the module of the wrapper contains an initial statement that specifies the $cosim_handelc PLI task. $cosim_handelc is a non-standard system task that initializes the communication interface during the simulation startup. Its parameters (they cannot be renamed) are passed to the simulator: the name of the library (*.dll) containing compiled Handel-C model (HANDELC_SIMULATOR) and the name of the Verilog wrapper (MODELNAME) for the HandelC model, respectively. You can specify both the name of the model and the path to the DLL file by using the $MODELNAME and $HANDELC_SIMULATOR variables, respectively (the value of the variable can be set by using the set macro command) or set them on the Handel-C Code Debug and Co-simulation Settings tab of the C/Handel-C Code Debug Settings window. Using the Verilog wrapper requires the specification of the co-simulation plug-in (AldecHandelC.dll). In VHDL designs, it is defined by the foreign attribute while in Verilog you need to specify it on the Verilog PLI tab of the Design Settings window. See the PLI Reference Guide or the Active-HDL Interfaces and Application Notes chapters for more information on the built-in PLI interface. The example of the Verilog wrapper is presented below.
7. Save the wrapper and compile the source file.
128
VHDL Debugging
Specifying Co-simulation Settings

The next step is to setup the co-simulation environment (co-simulated unit and library). 8. Open the C/Handel-C Code Debug Settings window and switch to the Handel-C Code Debug and Co-simulation Settings tab. 9. Enter the name of the wrapper unit in the Define Model Name field. The simulation library (Example1.dll) should already be specified in the Select Handel-C Library for Debugging and Co-simulation filed. The dialog box is shown in the figure below. Then, close the dialog box.
Setting the name of the wrapper generates the following message to the Console window: # set HANDELC_SIMULATOR C:\Program Files\Celoxica\DK\Examples\HandelC\Example1\Debug\Example1.dll # set MODELNAME wrapper You can also set these arguments by using the set macro command.
Preparing Testbench
After you have modified the source code of the Handel-C model, created the wrapper, and specified the co-simulation settings, you can proceed to simulate the design. To do so, you will need a testbench that will stimulate your mixed-language project. You can use the following example of the VHDL ...
129
Application Notes library IEEE; use IEEE.std_logic_1164.all; entity testbench is end entity; architecture testbench of testbench is signal data: STD_LOGIC_VECTOR(7 downto 0); signal result: STD_LOGIC_VECTOR(15 downto 0); component wrapper is port ( data_out : out STD_LOGIC_VECTOR (15 downto 0); data_in: in STD_LOGIC_VECTOR (7 downto 0)); end component; begin STIMUL: process begin data <= "00000000"; wait for 200ns; data <= "00000001"; wait for 200ns; data <= "00000010"; wait for 200ns; data <= "00000011"; wait for 200ns; data <= "00000100"; wait; end process STIMUL; UUT: wrapper port map (result,data); end architecture; or Verilog testbench: `timescale 1ps/1ps module testbench(); wire [15:0] result; reg [7:0]data; initial begin #0 data = 8'b0000000; #200000 data = 8'b00000001; #200000 data = 8'b00000010; #200000 data = 8'b00000011; #200000 data = 8'b00000100; end wrapper UUT (data,result); endmodule
130
VHDL Debugging 10. Copy the source code presented above to a new empty window in the HDL Editor and add it to the design. To do so, choose the Add Current Document option from the Design menu. 11. Enter testbench in the File name field and click Save in the Save As dialog box. 12. Compile the testbench.v(hd) file and set the testbench unit as the top-level unit. If you use the Verilog wrapper, before you initialize the simulation, you need to define the path to the co-simulation plug-in ($ALDEC\Bin\AldecHandelC.dll). In VHDL designs, it is defined by the foreign attribute while in Verilog, you need to specify it on the Verilog PLI tab of the Design Settings window that is shown in the figure below.
Running Co-simulation
13. Initialize the simulation by choosing the Initialize Simulation command from the Simulation menu. 14. Click the Structure tab and select the testbench unit. 15. Open a new waveform window. 16. Add the data_in and data_out signals by dragging the UUT instance to the waveform or by selecting the signals and choosing Add to Waveform from the pop-up menu. 17. Choose the Run Until option and enter 1.2us in the dialog box. Then, click OK. You can also type in the run 1.2us command in the Console window and press Enter. The simulation will advance to 1.2us. Depending on the language used to describe the wrapper, the figures shown below present the simulation results for the co-simulated Handel-C unit instantiated in the VHDL ...
131
Application Notes
or Verilog wrapper, respectively.
132
Using Celoxica Flowchart

Introduction
With the growing complexity of today's designs, the methodology of a hardware description is changing and it forces designers to search for new solutions, design tools, or even description languages that could be used to specify the behavior of digital devices. The Active-HDL's Design Flow Manager provides a flowchart and interface to Celoxica's HandelC-to-hardware DK Design Suite. Introducing the flowchart allows the DK Design Suite users to run the tool directly from Active-HDL and "translate" their Handel-C-based designs to VHDL, Verilog, or EDIF that can be then verified in the integrated simulation environment. This application note will help you get familiar with the Celoxica flowchart and show you how to use it in Active-HDL. In this application note, we will use the Celoxica's sample project of a FIR filter stored in the <DK_Design_Suite_directory>\examples\vhdl\example3 subdirectory.
Creating a sample design

1. Start Active-HDL by going to the Start | Programs group and click the Active-HDL icon. The Active-HDL Welcome screen appears and then the Getting Started dialog opens. 2. Select the Create new workspace option and click the OK button. You can alternatively use the File | New | Workspace option to open the New Workspace window. 3. The New Workspace wizard appears. In the wizard's dialog, you can enter the name and location of the workspace. Enter filter in the Type the workspace name field. Make sure that the Add New Design to Workspace checkbox is selected. 4. Click the OK button. When you close the New Workspace wizard, the New Design Wizard will be loaded. 5. Select Add existing resource files and press Next. 6. Add the following source files and then click Next: receiver.hcc filter.vhd wrapper.vhd
133
Application Notes 7. Choose the settings as it is shown in the figure below.
8. In the last wizard's window, specify the name of the design, disable the Compile source files after creation option, and click Finish. The design tree is presented below.
Setting Options for Celoxica Flowchart

9. Go to the Design menu and choose Flow Settings.
134
Using Celoxica Flowchart 10. From the C Synthesis section, choose Celoxica. Next, close the Flow Configuration Settings window. 11. Before you run Celoxica, you need to specify the C-synthesis settings. To do so, press the Celoxica's Options button in the Design Flow window. 12. In the Celoxica Options window, specify the top-level unit, target format, family, device, and speed grade. Click OK to complete.
13. Now, you have specified in Active-HDL all the settings required to run C-synthesis with the Celoxica's environment. Pressing the Celoxica button in the Design Flow window starts DK Design Suite and loads the Example3 sample design. The design contains only one source file receiver.hcc.
14. Before you start building, you should select the VHDL configuration. In order to select it, choose Set Active Configuration from the Build menu or use the pull-down menu as it is shown in the figure below
135
Application Notes
15. After the active configuration has been set, you can build the project by using the Build (F7) command from the Build menu or clicking from the toolbar. When the project is built, you can find on the Build tab information on an estimated usage of resources.
16. Close DK Design Suite and switch to Active-HDL. After the project has been built, the Celoxica subfolder is created in the design folder. In this folder, the files generated by DK Design Suite will be stored. The Refresh File List button in the Design Flow window (next to the Celoxica button) allows you to point to the files that should be added to the filter design. Press the browsing button (...) in the Choose Source File dialog box and then select the required files from $DSN\Celoxica\Vhdl. The design tree containing all the files is presented below.
Synthesizing the Design

17. Open the Synthesis Options window. In this window, specify the name of the top-level unit (wrapper) and other options on the General tab as it is shown below.
136
18. Open the Libraries tab and specify a library (alias) used by the synthesis tool. Click Add Alias, type in HandelC and press OK. In the Add File window, browse to the $ALDEC\Vlib\handelc\src subfolder and select the handelc.vhd file. Next, press the Open button.
19. Close the Synthesis Options window by clicking OK. When you specify all settings you can run the synthesis by pressing the Synthesis button in the Design Flow window. After the synthesis has finished, you can view the synthesis report in the window shown below or by opening the log file.
137
Application Notes
The post-synthesis subfolder is added to the design tree. It contains two files: wrapper.edf used by the implementation tool and wrapper.vhm that can be used to run post-synthesis simulation. Now, we can proceed to start an implementation process.
Implementing the Design

20. You can run the implementation with the default settings or modify them in the Implementation Options window. In this window, after you specify all settings you can run the implementation by pressing the Implementation button in the Design Flow window.
138
You can review the implementation report in the window shown below or open the log file in the HDL Editor window.
After the implementation has completed, you can compile time_sim.vhd and run the timing simulation of the filter design, which allows you to check the implementation results.
139
Application Notes For more information on using the Design Flow Manager during compilation, post-synthesis, and timing simulation, see the Post-Synthesis and Timing Simulation topic in the on-line documentation.
140
Using TestBencher Pro with Active-HDL

Introduction
Active-HDL provides the built-in testbench generation, however, it also allows using testbenches coming from external verification tools. This application note will show you how to use SynaptiCADs TestBencher Pro with Active-HDL. In this application note, we will create a testbench for the V_FMeter sample design that is installed along with Active-HDL.
Creating a New Project

1. Start TestBencher Pro and choose the New Project option from the Project menu. 2. In the New Project Wizard window, specify the settings as it is shown in the figure below.
3. Choose default settings in subsequent dialogs and in the last dialog press Finish to complete the creation of the new design. The Project - V_FMeter_Testbench.hpj window opens.
Now, we will add the source files of the V_FMeter design to the TestBencher Pro project. 4. Right-click the User Source Files folder and choose Add Files to User Source File Folder from the pop-up menu. 5. In the Add File(s) window, open the folder where the V_FMeter sample design is stored (C:\My_Designs\Samples\V_FMeter\src).
NOTE: In this application note, we use a non-default location of the sample design.
141
Application Notes 6. Select Bin2bcd.v and Hex2led.v. Click OK to add the selected files. 7. Change the path to C:\My_Designs\Samples\V_FMeter\compile and select remaining source files generated from the Block and State Diagram Editor: cnt10b.v, control.v, and freq_m.v. The Project window is shown below.
8. Click the Extract the MUT ports into Diagram button, which starts parsing the design and extracts Model Under Test (MUT). Extracting MUT allows then choosing the top-level module for which the testbench is to be created. After the structure has been parsed, the top-level module (freq_m) is extracted and displayed in the Simulated Model folder of the Project window. The Project window is presented in the figure below.
The results of project parsing are generated during the compilation and displayed in the Report window.
142
Using TestBencher Pro(TM) with Active-HDL
Creating Stimuli
Before the testbench is generated, we need to create stimuli for input signals by editing the newly opened timing diagram window containing the extracted top-level signals. 9 To mark the signal as observed (FULL, LED_A, LED_B, LED_C, and LED_D), double-click it and set the Watch check box in the Signal Properties window. All signals that will be forced (inputs) are displayed in black whereas all observed signals cannot be edited and they are displayed in gray. The window with the selected signals is presented below.
10. Next, we create timing transactions for the input signals and save them in the stimulus.btim file. The window presenting transactions for the F_CONV, RESET, START, F_INPUT, and F_PATTERN signals is shown below.
After the transactions have been specified, we need to add a time marker that points to the end simulation time. 11. To add the time marker, click the Marker button and go to the end simulation time point. Click with the right-mouse button to insert the time marker. The vertical line is inserted.
143
Application Notes 12. Double-click it and set the options in the Edit Time Marker window as it is shown in the figure below.
13. Click OK to apply the settings and then save the file. The Diagram - stimulus.btim window is presented in the figure below.
NOTE: For more information on creating timing transactions and adding time markers, refer to Waveformer Pros on-line documentation.
14. Add stimulus.btim to the Transaction Diagrams folder by right-clicking the list of signals in the Diagram - stimulus.btim window and choosing the Add Diagram To Transaction Diagram Folder option. The Project window with stimulus.btim added to the Transaction Diagrams folder is shown below.
144
Now, you can generate the testbench file for the freq_m simulated model. The testbench will be generated into the V_FMeter_Testbench.v file. Before it is used during simulation, you need to specify the task that calls a subroutine generating test vectors for MUT. 15. First, generate the testbench by clicking the Generate Test Bench button or right-click Component Model (V_FMeter_Testbench.v) and choose the Generate Test Bench option. 16. Next, double click Component Model (V_FMeter_Testbench.v) to open the testbench file and insert the cursor in the code as it is shown in the figure below.
17. Choose the Insert Diagram Calls option from the context menu. The Insert Diagram Subroutine Call window shown below will open.
145
Application Notes
18. You can use the default settings (Run Once, Wait for Completion) and then click Insert. After the task has been inserted to the code, save the testbench file and close it. The modified code is as follows:
Now, the testbench is ready-to-use. However, before you compile the TestBencher project, you need to specify the target simulator that will be used to simulate MUT (freq_m) with the generated testbench. 19. To set the simulator, go to the Options menu and choose the External Program Settings option. After the External Program Settings window opens, set the Enable External Program Integration checkbox and choose Active-HDL from the Simulator list box. In the Target OS list box, choose Windows based and then point to the \Bin subfolder of the Active-HDL installation in the Simulator Path field. The settings are presented below.
146
20. Press OK to apply the settings. Now, all the TestBencher Pro settings are specified and you can compile the project. 21. Press the Compile Model and Test Bench toolbar button or choose Build (F7) from the Simulate menu. This option starts VSimSA and the process of the design compilation. You can observe compilation results on the simresult.txt tab of the Report window.
After the design has been compiled, you can run the simulation with the newly created testbench. 22. To start the simulation, click the Run/Resume Simulation button or choose Run from the Simulation menu. The simulation report is displayed during the simulation on the simresults.txt tab of the Report window.
147
Application Notes
Simulation data is saved in the waveform file that can be loaded to the Active-HDL Waveform Viewer window. The waveform window is presented in the figure below.
148
Building PLI Applications

Introduction
The Verilog PLI, or Programming Language Interface, provides a standard mechanism that allows designers to access and modify data in a simulated Verilog model. The PLI interface allows creating user-defined tasks and functions that interact with Active-HDL. Then, they can be placed directly in HDL source code or called interactively from the Console window. Active-HDL provides both the PLI interface linking applications to the simulator and tools that allow designers to compile and debug them within one integrated environment. This application note will show you how to create, compile, and build a PLI application in ActiveHDL by using the PLI Wizard, PLI Interface, and C-related built-in features and tools.
Building PLI Application

Active-HDL loads PLI applications dynamically during the initialization of simulation. Therefore, they must be compiled and linked to a shared library. The PLI applications are loaded by using operating system calls and their building process may differ on different operating systems. In this application note, we will focus on the platform used by Active-HDL.
Header Files The \PLI\Include subdirectory of the Active-HDL installation directory contains header files that must be included in every PLI application. #include <veriuser.h> #include <aldecpli.h> The aldecpli.h header file contains an include directive for the acc_user.h header file. The PLI applications must be registered through an array of s_tfcell structures. The structure is defined in the aldecpli.h file. typedef struct t_tfcell { short type; int data; int (*checktf)(); int (*sizetf)(); int (*calltf)(); int (*misctf)(); char* tfname; /* The following fields are ignored */ int forwref; char *tfveritool; char *tferrmessage; int hash; struct t_tfcell *left_p; struct t_tfcell *right_p; char *namecell_p; int warning_printed; } s_tfcell, *p_tfcell;
149
Application Notes Compiling and Linking Sources To compile a PLI application, you can use any C/C++ compiler e.g. Microsoft Visual C++. If Microsoft Visual C++ is used, the aldecpli.lib library needs to be added to the Resource Files folder. It is located in the \PLI\Lib subdirectory of the Active-HDL installation directory. Next, add a definition file to the Header Files folder. The definition file should contain the following entry: EXPORTS veriusertfs DATA Assuming that the source code for your PLI application is located in the mypli.c file, the project workspace will look like in the figure below:
To use a PLI application in Active-HDL, you can compile source files by using any C/C++ compiler. However, to be able to debug the application in Active-HDL, it needs to be compiled with a tool producing Gdb-compatible debug information. The installation of Active-HDL provides the Gcc compiler and the Gdb debugger that can be used to compile and debug PLI applications that will then be loaded to the simulation environment. This application note is based on Active-HDLs hex2bin_bde sample design. The purpose of this example is to show how to create and compile C/C++ applications in Active-HDL and how to link them to HDL designs. In this design, we will create a simple application that lists in the Console window the structure of the design.
Loading sample design

1. The first step is to load the hex2bin_bde sample design. To open it, choose Open Workspace/Design Explorer from the File menu. Then, double-click the hex2bin_bde workspace icon (\Samples\Verilog_Designs).
150
Building PLI Applications 2. The workspace you have just opened contains the design that needs to be compiled before you proceed with the simulation. To compile it, choose the Compile All Design menu. command from the
3. After the successful compilation, set top-level by clicking the Top-Level selection list box and selecting the UUT_PLI unit as it is shown in the figure below.
Creating PLI Application

After you have specified the design top-level, you can proceed to create a PLI application. The PLI Wizard is a tool that simplifies the creation of PLI applications in the Active-HDL environment. The wizard will help you select the name of the PLI task/function, its parameters, values, and it will fill the veriusertfs table stored in the veriuser_aldec.cpp file. As an output, the PLI Wizard will create C templates for PLI routines. In our sample design, we will use a single PLI routine stored in a single C source file. The PLI Wizard option is available from the Tools menu and it can be run only when the design is loaded. 4. To start creating the PLI routine template, choose VHPI/PLI Wizard from the Tools menu. 5. Switch to the PLI Wizard tab and type in structure in the System task/function name and Calltf routine fields. 6. Set the remaining options as it is shown in the figure below.
151
Application Notes
7. When the settings are specified, press Modify list, then Generate, and close the window by clicking OK. 8. Except the C source file, the PLI Wizard also generates additional files into the \PLI subfolder. They are required while compiling a C source code by using Microsoft Visual Studio. Since Active-HDL provides the Gcc compiler, we will use only the generated C source files. The Console window lists all files that have been create by the PLI Wizard.
# Design: Created file C:\My_Designs\HEX2BIN_BDE\src\PLI\pli.set # Design: Created file C:\My_Designs\HEX2BIN_BDE\src\PLI\veriuser_aldec.cpp # Design: Created file C:\My_Designs\HEX2BIN_BDE\src\PLI\structure_pli.cpp
The design tree with the new \PLI subfolder is shown in the figure above. The generated structure_pli.cpp file contains only an empty template of the calltf routine. In order to achieve our aim and allow displaying the structure of the design, we will add one more function and modify the calltf one. Since we are going to use the Gcc compiler, we will pay our attention only to the update of the structure_pli.cpp source file. 9. Double-click structure_pli.cpp to load the file into the HDL Editor window. The template file is shown in the figure below.
10. Add the following header file declaration at the beginning of the source file: #include "aldecpli.h"
152
Building PLI Applications 11. Enter the following code below the line starting with //--Enter your function here-//:
int level=0; void printNextBranch(handle module_handle) { handle child_handle = null; // scan recursively beginning with top-level modules while (child_handle = acc_next_child(module_handle, child_handle)) { io_printf("%s\n", acc_fetch_fullname(child_handle)); printNextBranch(child_handle); } } The modified User function section of structure_pli.cpp is shown in the figure below.
12. Modify the structure routine by adding the following code: int structure ( ) { // -- Enter your statements here -- // // initialize environment for access routines acc_initialize(); printNextBranch(null); acc_close(); return (0); } The modified routine is shown in the figure below.
13. Save the source file.
153
Application Notes The structure_pli.cpp sample PLI application allows printing in the text mode the structure of the design to the Console window. The application is registered in the veriusertfs array. The entry in the array registers usertask. The task is registered as a calltf routine. Every time Active-HDL encounters a $structure task in the Verilog code, it will execute the structure function. The function calls printNextBranch() that scans recursively the structure of the design. Handles to subsequent modules are obtained with acc_next_child(). Once you have the module handle, you can get the name of the module with acc_fetch_fullname(). Active-HDL provides an interface to the Gcc compiler that can be used to build user-defined PLI or VHPI applications. Before you compile any C/C++ source code, you may want to check a configuration file for your application. In this case, the configuration is stored in the HEX2BIN_BDE.dlm file that contains information on source files to compile along with include files, required libraries, compiler and linker options. To check the configuration: 14. Double-click the HEX2BIN_BDE.dlm file. The C/C++ Configuration dialog window opens, which allows you to specify all options required to build the PLI application. These options are: the name and location of the DLM configuration file (Configuration Name), the name and path to the DLL file (it will be set automatically, however, if required you can specify another settings for both files by entering them manually or by using the Browse buttons), the type of the application to be built (selected from the Library type list box), the list of source files and libraries as well as compiler and linker options. 15. Enter structure.dll in the C/C++ library name field.
When all the options are specified, click Save to apply the changes.
16. Click HEX2BIN_BDE.dlm with the right-mouse button and choose Build from the context menu. After structure.dll has been built, you need to point to this file in order the simulator to load it during the simulation. 17. Choose Settings from the Design menu.
154
Building PLI Applications 18. Switch to the Verilog PLI tab and add structure.dll to the PLI Applications list. The Design Settings window is presented below.
19. Initialize the simulation by selecting the Initialize Simulation option from the Simulation menu. During the initialization of the simulation, the simulator loads the PLI application, which is reported to the Console window.
# KERNEL: PLI/VHPI kernel's engine initialization done. # PLI: Loading library 'c:\My_Designs\HEX2BIN_BDE/src/structure.dll'
In order to display the structure of the hex2bin_bde sample design, you should call the $structure task. You can call it interactively from the Console window. To print the structure of the design to the Console window, type in the following command: $structure This calls the $structure task and prints the design structure in the Console window:
# # # # # # # # # # # # # # # # UUT_PLI UUT_PLI.CNV UUT_PLI.CNV.U1 UUT_PLI.CNV.U2 UUT_PLI.CNV.U3 UUT_PLI.CNV.U3.U1 UUT_PLI.CNV.U3.U2 UUT_PLI.CNV.U3.U3 UUT_PLI.CNV.U3.U4 UUT_PLI.CNV.U4 UUT_PLI.CNV.U5 UUT_PLI.CNV.U5.U0 UUT_PLI.CNV.U5.U1 UUT_PLI.CNV.U5.U2 UUT_PLI.CNV.U5.U3 UUT_PLI.CNV.U6
The execution of the task is reported by the simulation kernel in the Console window:
# KERNEL: Task "$structure" execution completed
155

Introduction
VHPI, or VHDL Procedural Interface, provides a standard mechanism that allows designers to access data in a simulated VHDL model. The interface is implemented as a library of C functions. The VHPI implementation in Active-HDL complies with the standard being developed by the IEEE. The VHPI interface in Active-HDL provides the following functionality: Access to Static VHDL Data This provides access to behavioral and structural parts of the elaborated model. A user application can, for example, traverse the hierarchy of a VHDL design, fetch properties of VHDL objects or navigate between objects of a specific type. Access to Dynamic VHDL Objects This functionality enables reading values of VHDL objects such as signals or variables. A value can be fetched in a few different formats described by the VHPI specification. Simulation Interaction and Control The simulation interaction is achieved by registering callbacks to happen for specific conditions. A callback is a communication mechanism between the Active-HDL simulator and users C code. Foreign Model Instantiation and Intercommunication Mechanism VHPI user applications have to be registered during simulation startup in order to work properly. The registration mechanism uses VHPI foreign architectures. For general information on VHPI, refer to VHPI Standard Specification. For more information on the VHPI support and a list of constructs supported by Active-HDL, see the Active-HDL on-line documentation.
Active-HDL provides both the VHPI interface linking applications to the simulator and tools that allow designers to compile and debug them within one integrated environment. This application note will show you how to create, compile, and build a VHPI application in ActiveHDL by using the VHPI Wizard, VHPI Interface, and C-related built-in features and tools.
Building VHPI Application

Active-HDL loads VHPI applications dynamically during the initialization of simulation. Therefore, they must be compiled and linked to a shared library. VHPI applications can be registered either though a foreign model, that is a foreign architecture or a foreign subprogram. In this application note, we will focus on a registration based on a foreign architecture
Header Files The \PLI\Include subdirectory of the Active-HDL installation directory contains header files that must be included in every VHPI application. #include <vhpi_user.h> #include <aldecpli.h> The aldecpli.h header file contains the include directive for the acc_user.h header file (\PLI\Include). The aldecpli.lib file needed to link VHPI libraries under Windows is located in the \PLI\Lib subdirectory.
157
Application Notes
Registering VHPI Applications Each VHPI library must include at least one function to register VHPI tasks. A pointer to this function is located in the vhpi_startup_routines array. The array must be null terminated. Names of the registering functions are arbitrary, for example: PLI_VOID (*vhpi_startup_routines[])() = { startup_1, startup_2, null }; Functions that register VHPI tasks, for example startup_1, use the standard VHPI function vhpi_register_foreignf(). The vhpi_register_foreignf() function must be passed a pointer to the vhpiForeignDataT structure, for example: PLI_VOID startup_1() { vhpiForeignDataT foreignDatap = { vhpiArchFK, "myvhpi", "myvhpitask", elabf_1, execf_1 }; vhpi_register_foreignf(&foreignDatap); } The vhpiForeignDataT structure is defined in the vhpi_user.h header file. It includes five elements: vhpiArchFK This constant specifies that the foreign model is an architecture. The following constants can be used depending on the foreign model: - vhpiArchFK specifies that the foreign model is an architecture - vhpiProcFK specifies that the foreign model is a procedure - vhpiFuncFK specifies that the foreign model is a function char *libraryName The name of the library containing VHPI routines. The name can be either absolute or relative to the Active-HDL current directory. If you omit the extension, Active-HDL will automatically add the default .dll extension. If the library cannot be found in the current directory, Active-HDL will check the locations pointed by the PATH system variable. char *modelName The name of the VHPI task that appears in the VHDL foreign attribute string. void (*elabf) (const vhpiCbDataT* cbdata) Pointer to the callback function for the elaboration of the foreign architecture. This function can only reference objects within the instance of the architecture that called the function. void (*execf) (const vhpiCbDataT* cbdata) Pointer to the callback function for initialization of the foreign architecture. This function can access the whole VHDL design.
158
Building VHPI Applications Compiling and Linking Sources To use a VHPI application in Active-HDL, you can compile source files by using any C/C++ compiler. However, to be able to debug the application in Active-HDL, it needs to be compiled with a tool producing Gdb-compatible debug information. The installation of Active-HDL provides the Gcc compiler and the Gdb debugger that can be used to compile and debug VHPI applications that will then be loaded to the simulation environment. This application note is based on Active-HDLs datapath sample design. The purpose of this example is to show how to create and compile C/C++ applications in Active-HDL and how to link them to HDL designs. In this design, we will create a simple application that will search for design signals, components, and processes and then list them in the Console window.

1. The first step is to load the datapath sample design. To open it, choose Open Workspace/Design Explorer from the File menu. Then, double-click the datapath workspace icon (\Samples\VHDL_Designs).
2. The workspace you have just opened contains the design that needs to be compiled before you proceed with the simulation. To compile it, choose the Compile All Design menu. command from the
3. After the successful compilation, set top-level by clicking the Top-Level selection list box and selecting the top_testbench (tb_architecture) unit as it is shown in the figure below.
159
Application Notes
Creating VHPI Application

After you have specified the design top-level, you can proceed to create a VHPI application. The VHPI Wizard is a tool that simplifies the creation of VHPI applications in the Active-HDL environment. The wizard will help you select the name of the VHPI architecture/function/architecture name, its parameters, values, and it will fill the foreignDataArray table stored in the vhpiuser_aldec.cpp file. As an output, the VHPI Wizard will create C templates for VHPI routines. In our sample design, we will use a single VHPI routine stored in a single C source file. The VHPI Wizard option is available from the Tools menu and it can be run only when the design is loaded. 4. To start creating the VHPI routine template, choose VHPI/PLI Wizard from the Tools menu. 5. On the VHPI Wizard tab, type in dump_hierarchy in the VHDL procedure/function/architecture name field. 6. Set the remaining options as it is shown in the figure below.
7. When the settings are specified, press Modify list, then Generate, and close the window by clicking OK. 8. Except the C source file, the VHPI Wizard also generates additional files into the \VHPI subfolder. They are required while compiling a C source code by using Microsoft Visual Studio. Since Active-HDL provides the Gcc compiler, we will use only the generated C source files. The Console window lists all files that have been create by the VHPI Wizard.
# # # # Design: Design: Design: Design: Created Created Created Created file file file file C:\My_Designs\Datapath\src\VHPI\vhpiuser_aldec.cpp C:\My_Designs\Datapath\src\VHPI\dump_hierarchy_vhpi.h C:\My_Designs\Datapath\src\VHPI\dump_hierarchy_vhpi.cpp C:\My_Designs\Datapath\src\VHPI\dump_hierarchy_vhpi.vhd
160
The design tree with the new \VHPI subfolder is shown in the figure above. The generated dump_hierarchy_vhpi.cpp file contains only an empty template of the execf routine pointer. In order to achieve our aim, we will add one more function and modify the execf one. Since we are going to use the Gcc compiler, we will pay our attention only to the update of the dump_hierarchy_vhpi.cpp source file. The dump_hierarchy_vhpi.cpp sample VHPI application will search for signals, components, and processes, then count and list them in the Console window. 9. Double-click dump_hierarchy_vhpi.cpp to load the file into the HDL Editor window. The template file is shown in the figure below.
10. Add the following header file declaration at the beginning of the source file: #include "stdio.h" 11. Enter the following code below the line // put your code here: vhpiHandleT vhpiHandleT vhpiHandleT vhpiHandleT vhpiHandleT rootInstHdl = NULL; // handler to rootInst component iteratorSigHdl = NULL; // iterator for SigDecls Hdl = NULL; // handler archBodyHdl = NULL; // handler to archBody entityDeclHdl = NULL; // handler to entityDecl
int numObjs = 0; // initialize objects counter vhpi_printf("\nUsing VHPI application as Foreign Architecture to count declared signals..."); //1. if ( rootInstHdl = vhpi_handle(vhpiRootInst, NULL) ){ //2 // signal declarations if ( iteratorSigHdl= vhpi_iterator(vhpiSigDecls, rootInstHdl) ) //3. while ( Hdl = vhpi_scan(iteratorSigHdl) ){ // handler points to object of type vhpiSignalDeclK (signal) vhpi_printf("found signal: %s ", // signal name
161
Application Notes vhpi_get_str(vhpiNameP, Hdl)); numObjs++; } traverse_hierarchy(rootInstHdl, &numObjs); // fetching some information about analyzed design: // name of architecture of top level design if ( archBodyHdl = vhpi_handle(vhpiDesignUnit, rootInstHdl) ){ // name of entity of top level design if ( entityDeclHdl = vhpi_handle(vhpiPrimaryUnit, archBodyHdl) ){ vhpi_printf("============================================== ================"); vhpi_printf("SUMMARY:"); vhpi_printf("Analyzed entire design '%s' contains %d signal(s)", vhpi_get_str(vhpiNameP, entityDeclHdl), numObjs); } } } vhpi_printf("\nEnd of Your VHPI application......."); The modified routine is shown in the figure below.
12. Add the auxiliary traverse_hierarchy routine below the line with the header file declarations: PLI_VOID traverse_hierarchy(vhpiHandleT ScopeHdl, int *numObjs){ vhpiHandleT iteratorSigHdl = NULL; // iterator for SigDecls vhpiHandleT iteratorRegHdl = NULL; // iterator for InternalRegions vhpiHandleT Hdl = NULL; // handler vhpiHandleT SigHdl = NULL; // handler if (ScopeHdl==NULL) return;
162
Building VHPI Applications if ( iteratorRegHdl = vhpi_iterator(vhpiInternalRegions, ScopeHdl) ) //1. while ( Hdl = vhpi_scan(iteratorRegHdl) ){ //2. vhpi_printf("%s [%d]: %s ",vhpi_get_str(vhpiKindStrP, Hdl), vhpi_get(vhpiKindP, Hdl), vhpi_get_str(vhpiNameP, Hdl) ); // signal declarations if (iteratorSigHdl= vhpi_iterator(vhpiSigDecls, Hdl)) //3. while ( SigHdl = vhpi_scan(iteratorSigHdl) ){ // handler points to object of type vhpiSignalDeclK (signal) vhpi_printf("found signal: %s ", //signal name vhpi_get_str(vhpiNameP, SigHdl)); (*numObjs)++; } traverse_hierarchy(Hdl, numObjs); } } The modified dump_hierarchy_vhpi.cpp is shown in the figure below.
VHPI applications can be registered by using subprograms or through architecture with a foreign attribute (declared in the standard package of the std library). This example will show how to register the VHPI application by using the foreign architecture. The VHPI Wizard provides the dump_hierarchy_vhpi.vhd file that contains the declaration of the foreign attribute. To load the VHPI application during the initialization of simulation, we need to create an auxiliary entity/architecture pair that stores the declaration of the attribute. To do so: 13. Double-click dump_hierarchy_vhpi.vhd. 14. Modify the code of dump_hierarchy_vhpi.vhd by adding the entity and architecture declarations. The modified code is listed below.
163
Application Notes ------------------------------------------------------------------------------------------------------------------------------------------ Please put this declaration in architecture entity dump_hierarchy is end entity dump_hierarchy; architecture dump_hierarchy of dump_hierarchy is attribute foreign of dump_hierarchy : architecture is "VHPI VHPI\dump_hierarchy.dll; dump_hierarchy_model"; begin end architecture dump_hierarchy; ----------------------------------------------------------------------------------------------------------------------------------------15. Compile the file. Since we are going to proceed with registering the VHPI application through foreign architecture, we need to instantiate the dump_hierarchy unit within the selected top-level. 16. Open the testbench.vhd file. 17. Add the declaration of the dump_hierarchy component as it is shown in the figure below.
18. Next, add the component instantiation statement: APPLICATION_FROM_VHPI : dump_hierarchy; as it is shown in the figure below.
19. Save and compile the testbench.vhd file. Active-HDL provides an interface to the Gcc compiler that can be used to build user-defined PLI or VHPI applications. Before you compile any C/C++ source code, you need to specify a configuration file for your application. In this case, the configuration is stored in the datapath.dlm
164
Building VHPI Applications file that contains information on source files to compile along with include files, required libraries, compiler and linker options. To check the configuration: 20. Double-click the datapath.dlm file. The C/C++ Configuration dialog window opens, which allows you to specify all options required to build the VHPI application. These options are: the name and location of the DLM configuration file (Configuration Name), the name and path to the DLL file (it will be set automatically, however, if required you can specify another settings for both files by entering them manually or by using the Browse buttons), the type of the application to be built (selected from the Library type list box), the list of source files and libraries as well as compiler and linker options. 21. Enter dump_hierarchy.dll in the C/C++ library name filed.
When all the options are specified, click Save to apply the changes. 22. Click dump_hierarchy.dlm with the right-mouse button and choose Build from the context menu. After dump_hierarchy.dll has been built, you can initialize the simulation. 23. Choose the Initialize Simulation option from the Simulation menu. During the initialization, the application is registered through the VHDL foreign architecture, which is reported to the Console window. # KERNEL: PLI/VHPI kernel's engine initialization done. ... # VHPI: Loading library 'VHPI\dump_hierarchy.dll' Loading vhpiuser_aldec.dll starts analyzing the design and prints information on found signals, components, processes to the Console window: # : Using signals # : found # : found # : found # : found VHPI application as Foreign Architecture to count declared signal: signal: signal: signal: CLK RESET START CODE
165
Application Notes # : found signal: DATA_IN ... ... After the entire design has been scanned, the Console window displays information on the analyzed unit and the total number of found signals: # : ============================================================== # : SUMMARY: # : Analyzed entire design 'top_testbench' contains 29 signal(s) # : # : End of Your VHPI application. ... # Simulation has been initialized # Selected Top-Level: top_testbench (tb_architecture)
166
Debugging C/C++ Applications

Introduction
Active-HDL provides a debugging tool for users who need to verify VHPI/PLI applications attached to VHDL or Verilog designs. The C Code Debug option allows designers to debug DLLs being a part of the design. The simulation of the design along with the VHPI/PLI application is performed within the VSimSA environment through the built-in VHPI/PLI interface. The VHPI/PLI applications can be debugged by using the HDL Editor and C Code Debug windows and the simulator's output can be observed in the VSimSA window. The HDL Editor allows inserting breakpoints and tracing C/C++ code while the Console window allows entering and executing Gdb commands as well as viewing messages generated during the debugging session. To debug a DLL file, it should be compiled with the Gcc-compatible compiler producing the Gdb-compatible debug data. The installation program of Active-HDL installs tools that allow compiling and debugging C/C++ source code. The compiler (gcc.exe) and the debugger (gdb.exe) are parts of MinGW (Minimalist GNU for Windows Edition ver. 2.0.0) and they are installed in the \MinGW\bin subdirectory of the Active-HDL installation. This application note will guide you through the process of C/C++ code debugging and allows you to familiarize with capabilities of C/C++ compilation in Active-HDL. For additional information on compiling C/C++ applications, see the Building PLI Applications or Building VHPI Applications application notes. This application note is based on the hex2bin_bde sample design installed with Active-HDL.
NOTE: In order to use the C Code Debug option, the license for the batch mode simulation (VSimSA) is required.

1. The first step is to load the hex2bin_bde sample design. To open it, choose Open Workspace/Design Explorer from the File menu. Then, double-click the hex2bin_bde workspace icon (\Samples\Verilog_Designs).
2. The workspace you have just opened contains the design that needs to be compiled before you proceed with the simulation. To compile it, choose the Compile All command from the Design menu.
167
Application Notes 3. After the successful compilation, set top-level by clicking the Top-Level Selection list box and selecting the UUT_PLI unit as it is shown in the figure below.
Setting C Code Debug Options

4. Choose the C/Handel-C Code Debug Settings option from the Design menu. The C/HandelC Code Debug Settings dialog window opens. It provides configuration options that will be used while initializing the debugging session of your C/C++ or Handel-C application. Now, we will set options for the C/C++ debugging session (C Code Debug Settings tab). 5. Use the settings as it is shown in the figure below.
In this window, we specify options that among others will create and automatically add the generated macro to the design.
168
Debugging C/C++ Applications In the PLI Applications section, the list of DLL files is displayed. A PLI application is displayed in this section if you have added a DLL file to the Verilog PLI tab in the Design Settings window. In VHDL designs, VHPI applications are registered through architecture with a foreign attribute. The attribute is declared in the standard package of the std library. The foreign architecture could be defined as follows: architecture <architecture_name> of <entity_name> is attribute FOREIGN of <architecture_name>: architecture is "VHPI <library_name>; <model_name>"; For additional information on the options of the C Code Debug Settings and Design Settings windows or Using VHPI Applications, see the Active-HDL on-line documentation. 6. Click OK to close the dialog.
After the settings of the debugging session have been specified and you have closed the C/Handel-C Code Debug Settings window, the run_cdebug.do macro file that have been specified in the Startup Macro field is attached to the design tree, which is presented in the figure above.
Initialization of Debugging Session

7. To initialize the debugging session, choose the Initialize C Code Debug option from the Simulation menu. It starts the VSimSA simulator in a separate command prompt window and opens the C Code Debug window in Active-HDL as well as the HDL Editor window with a C/C++ source code. During the initialization of the debugging session, VSimSA displays in the command prompt window information on simulation environment, working library, and loaded VHPI/PLI library.
169
Application Notes The Console window displays additional messages related to breakpoints that have been set: # C Code Debug: Automatic breakpoint insertion enabled. # C Code Debug: C Code Debug session has been started. The Source files tab of the C Code Debug window lists all source files that have been compiled. By double-clicking a source file, you can open it in the HDL Editor that supports C/C++ syntax and keyword coloring, allows setting breakpoint and tracing a code.
After the debugging session has been initialized, the C/C++ source file is loaded and breakpoints are set automatically.
If required, you can set your own breakpoints by pressing F9 or choosing Toggle Breakpoint from the Simulation menu. Setting breakpoint will be reported in the Console window: # C Code Debug: C breakpoint id c.11 has been set: file: 'C:\My_Designs\HEX2BIN_BDE\src\external\read_byte_ex.c' line '74' function 'read_byte_ex_misctf'
170
Debugging C/C++ Applications The list of breakpoints that have been set is available in the Edit Breakpoints window (Simulation | Edit Breakpoints) shown below.
The initialization of the debugging session is denoted by the C Code Debug status that is shown in the Simulation Time/Status field .
Executing Gdb Commands

The C Code Debug window allows entering the Gdb commands to control the debugging session. In this application note, we will start the session by using the continue Gdb command.
8. Type in continue in the Gdb command field and press Execute. The command continues a program being debugged that has been suspended by a breakpoint. When the command is issued, the debugger starts and the HDL Editor displays the yellow debug line that is set on the first encountered breakpoint in the C/C++ source code. The HDL Editor window is presented in the figure below.
171
Application Notes Each command executed from the C Code Debug window is echoed into the Console window. It also displays values returned by executed commands, which is shown in the figure below.
You can also debug the C/C++ source code in the HDL Editor window by using the Trace Into , Trace Out , or Trace Over options from the Simulation menu or from the toolbar.
9. The C Code Debug window also allows you to observe functions and variables used in the C/C++ source code. The Call Stack tab allows you to view detailed information on subprograms and selected call stack objects declared in the code along with their values.
NOTE: To enable displaying objects on the Call Stack tab, you need to check the Enable Call Stack functions list option in the C Code Debug Settings dialog window.
In the Watch tab, you can add variables and observe their values during the debugging session. To add a variable: 10. Switch to the Watch tab. 11. Double-click the Expression column. This turns the editing mode on and you can enter the name of the item you want to observe e.g. in_file.
12. Press Enter to complete. 13. Repeat step #11 to add subsequent items e.g. chr, vec_size, and val (all the variables are defined in the read_byte_ex_calltf() function). Depending on the visibility scope i.e. the function being currently debugged, you may see Error: Not available displayed in the Value column.
172
Debugging C/C++ Applications When you start debugging the read_byte_ex_calltf() function the Value column will display the current values of individual variables. The Watch tab displaying added variables is shown above. After you have reached the end of the debugging process, you may want to finish the session. 14. To close the debugging session, choose End Simulation from the Simulation menu or type in the endsim command in the Console window.
NOTE: Closing the VSimSA command prompt window does not terminate the debugger and it is not allowed during the debugging session.
Compiling C/C++ Source Code

The hex2bin_bde sample design delivers the read_byte_ex.c source file and the pre-compiled read_byte_ex.dll library that just has been debugged. All the files are stored in the \external subfolder.
However, if you wanted to modify this PLI application or debug another DLL you would need to (re)compile a C/C++ source file. Active-HDL also provides an interface to the Gcc compiler that can be used to build user-defined VHPI/PLI applications. Before you compile any C/C++ source code, you need to specify a configuration file for your application. This configuration is stored in a DLM file that contains information on sources to compile along with include files and all required libraries, compiler and linker options. The hex2bin_bde sample design delivers the pre-defined configuration file. 15. Expand the \external subfolder. 16. Double-click the read_byte_ex.dlm file. It opens the C/C++ Configuration window (if you would like to create a new configuration file, choose C/C++ Configuration from the File | New menu.
173
Application Notes
In the C/C++ Configuration window, you can specify the name for the configuration file (DLM), your application (DLL), specify sources to be compiled including all required libraries, compiler, and linker options. When these options are specified, click Save to apply the changes. The DLM file is updated or, if you have just started creating a new configuration file, it is attached to the design tree as it is shown in the figure below.
17. To (re)compile the application click the DLM file with the right-mouse button and choose Build from the context menu. This option starts the compilation of sources files specified in the Files pane of the C/C++ Configuration window. When the compilation is completed, the DLL file is updated or, if you have just started creating a new application, it is attached to the design tree.
174
Using Design Profiler

Introduction
The design profiler included in Active-HDL allows to identify the portions of the design which consume most CPU power during simulation. Such information may give a valuable insight on how to reduce verification time. The profiler is built into the simulation kernel. The profiling process is completely non-intrusive. This document shows how to collect profiling data and how to identify portions of the design that are most expensive in terms of simulation time. Replacing a unit which puts a heavy strain on the simulator with another functionally equivalent implementation may result in a considerable performance improvement. If the design is run against many testbenches, the verification time can be considerably reduced. NOTES: The machine on which you run the design profiler should not be performing any other computationally intensive tasks. You may expect slight variations in the profiling results each time you run the same simulation. This is inevitable in the profiling process.
Collecting profiler data

To collect toggle coverage data for the project do the following: 1. Open the profiler_example workspace. The workspace contains two designs: modulator and profiler_example.
2. Load the runme_0.do macro in the HDL Editor and review its contents. The macro compiles design source files and then initializes and runs simulation. Note that the simulator is invoked with the following command: asim -profiler -tbp_dest $DSN/profiler_0 -profiler_hierarchy profiler_all modulator_0
175
Application Notes The -profiler switch enables profiling during simulation. The profiler will run in the hierarchical mode (-profiler_hierarchy). Profiling data will be saved to the profiler_0 subdirectory (tbp_dest $DSN/profiler_0). 3. When the simulation is complete, the macro starts the Profiler Viewer that shows the profiling data collected during simulation. The Profiler Viewer shows a design tree and several columns with profiling data. (Columns can be turned on or off by right-clicking on the column title and selecting column names from the pop-up menu.)
4. Focus on the Share with children and Time with children columns. The columns show how much CPU time each unit (and its subcomponents) occupied during simulation. The root level of the design shows statistics for the whole design. The total time (i.e. 100% share) is 69 362.44 time units. The multiplier_00 unit, one level below root, accounts for more than 70% of CPU usage during simulation. Accelerating this unit will have the largest impact on performance increase. 5. Click on the U3 unit in the design tree. The Profiler Viewer will display the source file for multiplier_00.
176
Using Design Profiler The multiplier_00 unit was compiled from the muliplier_00.vhd file. The implementation is fully synthesizable and consists of a number of adders and other basic components. In the next section multiplier_00 will be replaced with another, faster implementation.
Running the design with a modified multiplier

In this section you will run the design again with a modified version of the multiplier. The multiplier, previously compiled from the muliplier_00.vhd file will be replaced by a simpler implementation that can be simulated much faster: architecture multi_arch of multiplier_01 is begin Q <= A * B; end multi_arch; To see how the new multiplier impacts the performance of the simulator, do the following: 1. Select the runme_1.do macro in the Files tab on the Design Browser. Right-click on the file and choose Execute from the pop-up menu. The macro will compile required files, initialize and run simulation and then display profiling data in the Profiler Viewer. The profiling data will be saved to a different directory so that results generated in the previous run are not be overwritten. 2. Compare the total number of CPU ticks or the number of microseconds in the current simulation with the numbers obtained in the previous simulation run.
The profiling data shows that the total simulation time was reduced more than four times. The multiplier unit required less than 1.5 mln CPU ticks compared to well over 40 mln in the previous implementation. It now accounts for less than 10% of the total simulation time.
Optimizing the write process

The design includes two additional macros that run two other versions of the design. The runme_2.do macro uses modulator_1 instead of modulator_2. The modulator_2 contains an additional process that writes data to a file. The process is shown below in the Advanced Dataflow window. The profiling data is displayed below the dataflow view.
177
Application Notes
The runme_3.do macro uses modulator_3 instead of modulator_2. The modulator_3 architecture contains an optimized write process. The sensitivity list has been reduced to one signal only: Q_int. After running the runme_3.do macro you can check the effect of the optimization. The time the simulator needed to simulate the process was reduced by as much as 80%.
Conclusion
The design profiler can be used to make simulations run faster. Optimizing the design or the data dumping routines can yield manifold performance improvements. This can be a critical factor in an efficient verification process.
178
Using Toggle Coverage

Introduction
Toggle coverage reports describe design activity in terms of changes in signal values. Toggle coverage reports can identify a variety of issues in the design and the testbench, for example: Identify signals which were not initialized Locate areas of the design which are not properly tested by the testbench Measure power usage
This document shows how to collect toggle coverage statistics for the v_bjack project and how to correlate toggle coverage with code coverage.
Collecting toggle coverage data

To collect toggle coverage data for the v_bjack project do the following: 1. Start Active-HDL and open the v_bjack workspace. The v_bjack workspace is located in the Active-HDL\Samples\Verilog_Designs branch. 2. Compile all source files. Source files should be compiled in the following order: Gates.v, Bin2bcd.v, Bcd2led.v, Bjack_c.v (this file should be generated from Bjack_c.asf), Gen.v, Johnson8.v, Mux.v, V_bjack.v and Tb.v. This can be done either in the GUI or with the following command: alog -dbg $DSN\src\Gates.v $DSN\src\Bin2bcd.v $DSN\src\Bcd2led.v $DSN\src\Bjack_c.v $DSN\src\Gen.v $DSN\src\Johnson8.v $DSN\src\Mux.v $DSN\src\V_bjack.v $DSN\src\Tb.v 3. Locate the Tb.v file on the Files tab, select the V_Bjack_tb top-level module icon below and select Set as Top-Level from the pop-up menu.
4. Select Initialize Simulation from the Simulation menu. Active-HDL will load the design. 5. The toggle coverage engine can be controlled from the command-line with simple macro commands. To initialize toggle coverage for the v_bjack project, use the following command: toggle -xml v_bjack.xml -toggle_type full -type -rec UUT/* The command specifies that data for the toggle coverage report should be collected from all signals in the UUT region and all its subregions (-rec UUT/*). Information about signal types will be included in the report (-type). The toggle report will be created in the full mode (-toggle_type full). In the full mode, the report shows if both a rising and a falling edge occurred on monitored signals. The report format will be saved to the v_bjack.xml file (-xml v_bjack.xml).
179
Application Notes 6. To run simulation, select the Run command from the Simulation menu. The simulator will run simulation until there are no more events to process. When simulation finishes, select the End Simulation command from the Simulation menu. Toggle coverage report will be saved automatically to the toggle subdirectory. 7. You can display the XML report in any browser supporting XML, as shown in the picture below.
8. Starting with Active-HDL 6.2, toggle coverage data can be viewed in a dedicated Toggle Coverage Viewer. The functionality of the Toggle Coverage Viewer is much enhanced over a regular browser. To start the toggle coverage report in the Toggle Coverage Viewer, select Toggle Coverage from the View menu. A stand-alone Toggle Coverage Viewer window will be displayed. 9. Select the Open command from the File menu, go to the toggle subdirectory and open the v_bjack.xml report.
The Filter button and the neighboring combo box allow to filter out signals depending on whether they toggled during simulation. 10. By default the Toggle Coverage Viewer displays all signals in a flat view. To group signals by the hierarchy region, click the Show/hide hierarchy browser button on the toolbar.
180
Using Toggle Coverage
Correlating code coverage data with toggle coverage data

If you want to verify how well your design was exercised by the testbench, you may confront code coverage results with toggle coverage results. The code coverage viewer shows how many times each HDL statement executed during simulation. Code coverage data for the v_bjack project is shown below. (For details on using code coverage consult Active-HDL documentation.)
The Code Coverage Viewer shows statistics for a Johnson counter located in the UUT/I17 region. All executable statements defining the counter were executed at least once. Toggle coverage data for the same region is displayed below.
181
Application Notes
Toggle coverage reveals that several signals in the examined region (e.g. the tmp register) did not toggle. The example shows that combining toggle coverage with code coverage can provide the most comprehensive information about how well the design was exercised by the testbench.
182
Co-simulating VHDL and System-C

Introduction
Active-HDL allows to simulate designs containing units implemented in SystemC. Active-HDL provides all necessary tools including: C/C++ build environment SystemC 2.0.1 installation and pre-compiled SystemC libraries. (The Systemc.a library for the gcc compiler and a SystemC.lib library for the Visual Studio compiler.)
The C:\My_Designs folder contains a systemc_frequency_meter_vhdl design. The design has two versions: VHDL-only version Mixed VHDL-SystemC version
You will simulate both versions of the design and compare the output waveform files using the Compare Waveforms command from the Waveform menu.
Simulating VHDL-only version of the design

1. Select the Open Workspace/Design Explorer command from the File menu, locate the systemc_frequency_meter_vhdl design and double click on its icon. The design will be loaded in Active-HDL. 2. Double-click on the hdl_simulation.do macro file in the Design Browser. The macro will be loaded in the HDL Editor:
The macro compiles VHDL files, initializes simulation, adds selected signals to the Waveform Editor and runs simulation. 3. Click the Execute Script button on the toolbar. The macro will run the simulation process.
4. Save the waveform file as hdl_simulation.awf and close the Waveform Editor window. 5. Make sure that the Structure Tab in the Design Browser is selected and expand the /UUT/U1 branch:
183
Application Notes
The /UUT/U1 unit contains four instances of the CNT_4B 4-bit counter modeled in VHDL in the cnt_4b.vhd file. In the next stage all instances of the VHDL counter will be replaced by a counter modelled in SystemC.
Simulating mixed VHDL-SystemC version of the design

1. Click the Files tab in the Design Browser, locate the systemc_cosimulation.do macro, rightclick and select Execute from the pop-up menu. The macro will first recompile all design units. Note that the systemc_cnt_4b.vhd file will be compiled instead of the cnt_4b.vhd file that was used in the VHDL-only simulation. The systemc_cnt_4b.vhd file is a wrapper for a CNT_4B 4-bit counter implemented in SystemC. After compilation the macro will initialize simulation, add selected signals to the Waveform Editor and run simulation. 2. Save the waveform file displayed in the Waveform Editor window as systemc_cosimulation.awf. 3. Select Compare Waveforms from the Waveform menu and compare the systemc_cosimulation.awf file with the hdl_simulation.awf created in the HDL only simulation described in the previous section. Waveform comparison will not detect any differences. This indicates that VHDL and SystemC implementations of the counter are equivalent. 4. Click the Structure Tab in the Design Browser and expand the /UUT/U1 branch.
Note that the previously used cnt_4b architecture of the cnt_4b entity has been replaced by the systemc architecture. 5. Select any instance of the cnt_4b unit, right-click and select Implementation from the pop-up menu. The source file will be displayed:
184
Co-simulating VHDL and System-C
The SystemC module is instantiated in VHDL as a foreign VHDL architecture: attribute foreign of systemc : architecture is "VHPI $DSN\src\systemc\sc_cnt_4b.dll; sc_counter_inst"; The SystemC unit will be read from the sc_cnt_4b.dll library located in the src\systemc subdirectory.
The sc_cnt_4b.dll library

The SystemC-based model of the counter is loaded during the initialization of simulation from the vhpi_for_ahdl.dll library. The systemc_frequency_meter_vhdl design contains a pre-compiled version of this library. Build settings are stored in the vhpi_for_ahdl.dlm file. To review compilation settings, locate the vhpi_for_ahdl.dlm file in the systemc subdirectory, right-click and select open from the pop-up menu. The C/C++ Configuration dialog box will be displayed.
185
Application Notes Note that the Systemc.a library is included in the list of libraries to be linked with the target VHPI library. The names of source files are specified using the $DSN variable. The variable points to the design directory. To re-build the vhpi_for_ahdl.dll library, select the file in the sc_cnt_4b.dlm file in the Design Browser, right-click and select Build from the pop-up menu. The library will be built in the systemc subdirectory. The library is built from two source files: The sc_interface.cpp file defines the interface between SystemC units and the VHDL code
The sc_counter.cpp file contains the implementation of the counter in SystemC. The counter behavior is described in counter::behavior(). void counter::behavior() { if (Reset) { // Set counter contents to 0 Full=0; // FULL Flag to 0 countval=0; } else // active clock edge if rising edge of Clock 0->1 { if (Enable) // and enable equals 1 { if (countval == 9) // if COUNT=9 countval=0; else countval++; } } Q=countval; Full=(countval == 9) ? 1 : 0; //FULL =1 when COUNT == 9 otherwise 0 }
186
Co-simulating Verilog and System-C

Introduction
Active-HDL allows to simulate designs containing units implemented in SystemC. Active-HDL provides all necessary tools including: C/C++ build environment SystemC 2.0.1 installation and pre-compiled SystemC libraries. (The Systemc.a library for the gcc compiler and a SystemC.lib library for the Visual Studio compiler.)
The C:\My_Designs folder contains a systemc_frequency_meter_verilog design. The design has two versions: Verilog-only version Mixed Verilog-SystemC version
You will simulate both versions of the design and compare the output waveform files using the Compare Waveforms command from the Waveform menu.
Simulating Verilog-only version of the design

1. Select the Open Workspace/Design Explorer command from the File menu, locate the systemc_frequency_meter_verilog design and double click on its icon. The design will be loaded in Active-HDL. 2. Double-click on the hdl_simulation.do macro file in the Design Browser. The macro will be loaded in the HDL Editor:
The macro compiles Verilog files, initializes simulation, adds selected signals to the Waveform Editor and runs simulation. 3. Click the Execute Script button on the toolbar. The macro will run the simulation process.
4. Save the waveform file as hdl_simulation.awf and close the Waveform Editor window. 5. Make sure that the Structure Tab in the Design Browser is selected and expand the /UUT/U1 branch:
187
Application Notes
The /UUT/U1 unit contains an instance of the CNT_10B four bit counter modeled in Verilog in the cnt_10b.v file. In the next stage the Verilog counter will be replaced by a counter modelled in SystemC.
Simulating mixed Verilog-SystemC version of the design

1. Click the Files tab in the Design Browser, expand the SystemC subdirectory and select the cnt_10b.dlm file. The .dlm file contains build configuration for the PLI library that will be used in the simulation process.
Right click on the cnt_10b.dlm file and select Build from the pop-up menu. Active-HDL will launch the build process. The .dll library will be built in the systemc subdirectory. The output of the compiler will be shown in the Active-HDL console. 2. Click the Files tab in the Design Browser, locate the systemc_cosimulation.do macro, rightclick and select Execute from the pop-up menu. The macro will first recompile all design units. Note that the systemc_cnt_10b.v file will be compiled instead of the CNT_10b.v file that was used in the Verilog-only simulation. The systemc_cnt_10b.v file is a wrapper for the CNT_4B 4-bit counter implemented in SystemC. After compilation the macro will initialize simulation, add selected signals to the Waveform Editor and run simulation. 3. Save the waveform file displayed in the Waveform Editor window as systemc_cosimulation.awf. 4. Select Compare Waveforms from the Waveform menu and compare the systemc_cosimulation.awf file with the hdl_simulation.awf created in the HDL only simulation described in the previous section. Waveform comparison will not detect any differences. This indicates that Verilog and SystemC implementations of the counter are equivalent. 5. Click the Structure Tab in the Design Browser and expand the /UUT/U1 branch.
188
Co-simulating Verilog and System-C
Note that the previously used CNT_10B counter with one always block and two assign statements has been replaced by the CNT_10B wrapper with just one initial block. 6. Select the CNT_10B unit in the UUT/U1 branch, right-click and select Implementation from the pop-up menu. The source file will be displayed:
The SystemC module is instantiated in Verilog as a task called from the initial block: initial $sc_counter(CLK,RESET,ENABLE,FULL,COUNT);
The sc_cnt_4b.dll library

The simulator loads the $sc_counter task from the sc_cnt_4b.dll library located in the src\systemc subdirectory. All build settings are stored in the cnt_10b.dlm file. To review the settings, select the file, right-click and select open from the pop-up menu. The C/C++ Configuration dialog box will be displayed.
189
Application Notes
Note that the Systemc.a library is included in the list of libraries to be linked with the target PLI library. The names of source files are specified using the $DSN variable. (The variable points to the design directory.) When simulation is initialized, the name of the PLI library containing the implementation of the counter must be specified on the command line with the -pli cnt_10b.dll switch. The -pli switch specifies that the simulator should look for unknown tasks (i.e. the $sc_counter task) in the the cnt_10b.dll library. The library is built from two source files: The sc_interface.c file defines the interface between SystemC units and the Verilog code The sc_counter.cpp file contains the implementation of the counter in SystemC. The counter behavior is described in counter::behavior(). void counter::behavior() { if (Reset) { // Set counter contents to 0 Full=0; // FULL Flag to 0 countval=0; } else // active clock edge if rising edge of Clock 0->1 { if (Enable) // and enable equals 1 { if (countval == 0x3ff) // if COUNT_I == 10'b1111111111 countval=0; else countval++; } } Q=countval; Full=(countval == 0x3ff) ? 1 : 0; //FULL =1 when COUNT_I == 10'b1111111111 otherwise 0 }
190
Index
A Active-HDL Application Notes ..1, 15, 27, 37, 45, 54, 61, 71, 77, 85, 91, 99, 107, 133, 141, 149, 157, 167 B BASIC Scripting Capabilities Application Note........................................................54 Building and Debugging Handel-C Projects (Application Note).................................115 Building PLI Applications (Application Note) .............................................................149 Building VHPI Applications (Application Note) ....................................................157 C Celoxica (Using Celoxica Flowchart Application Note)..................................133 compiling Handel-C projects (Application Note) ....................................................115 compiling PLI applications (Application Note) .............................................................149 compiling VHPI applications (Application Note) ....................................................157 Co-simulating Verilog and System-C (Application Note).................................187 Co-simulating VHDL and System-C (Application Note).................................183 Creating FPGA and CPLD Designs Application Note .....................................71 D Debugging C Code Application Note.......167 debugging Handel-C projects (Application Note) ....................................................115 Design Entry Overview Application Note...15 Design Management Overview Application Note........................................................27 Design Profiler (Using Design Profiler Application Note) ................................. 175 G Glitches and Delta Cycle Handling Application Note .................................... 99 H Handling Libraries in VHDL Verilog and EDIF Application Note ........................... 37 How to Simulate Designs Application Note ............................................................... 77 P PLI (compiling PLI applications) ............. 149 Profiler (Using Design Profiler Application Note).................................................... 175 S Simulator Overview Application Note ....... 45 Starting Active-HDL Application Note ......... 1 T Tcl/Tk Scripting Application Note.............. 61 TestBencher Pro(TM) (Using TestBencher with Active-HDL Application Note) ...... 141 Toggle Coverage (Using Toggle Coverage Application Note) ................................. 179 U Using Celoxica Flowchart Application Note ............................................................. 133 Using Stimulators Application Note .......... 85 Using TestBencher Pro(TM) with ActiveHDL Application Note .......................... 141 V VHDL Debugging Application Note......... 107 VHDL Testbench Application Note ........... 91 VHPI (compiling VHPI applications) ....... 157
191

Application Notes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Notes

Uploaded by

Copyright:

Available Formats

Active-HDL

Copyright Aldec, Inc.

License agreement window.

3. Enter user personal data to work with the Active-HDL software.

Finishing the installation

NOTE: You should not uninstall Active-HDL manually.

Modification of previous installs

Hardware and Software Requirements

Files Installed in Windows Directories

Workspace and Design Structure

Active-HDL Configuration Settings

Built-in Standard Packages

Design Entry Overview

The HDL Editor

New Source File Wizard

Design Entry Overview

The New Source File Wizard.

Design Entry Overview

Code Auto Complete

State Machine Editor

Design Entry Overview

New Source File Wizard

State Machine Toolbars

Block Diagram Editor

Design Entry Overview

Defining the symbol architecture

Design Entry Overview

Design Management Overview

The New Design Wizard Window

Design Management Overview

Design Management Overview Text (.*) External file

Design Management Overview

Design Management Overview

Handling Libraries in VHDL, Verilog, and EDIF

Handling Libraries in VHDL, Verilog, and EDIF

Block Diagram Symbols

Library Units without Simulation Data

System Libraries vs. Design Libraries

The Library Manager window is shown below:

BASIC Scripting Capabilities

The context menu in the Waveform Editor window

The Default Set of Toggled Values

Rich Viewing Capabilities:

The Alphabetical Order

Bus And Signal Display

Simulation With Comments

BASIC Scripting Capabilities

The Go to Time Window

Comparing simulation runs

BASIC Scripting Capabilities

The Console Window

List of Available Commands

abort acom addvar addfile adel adir

BASIC Scripting Capabilities

alib amap architecture asim bd bp bs bsd cd change

ex, exa, examine expwave fc findstring force

fsm2vhd generatetb gettime goto help

BASIC Scripting Capabilities

list (add list)

noforce nolist nowave

open opendesign pause pwd quiet quit

radix removedesign removefile restart

view vlcomp wave wavecompare where