TOC PREV NEXT INDEX  

Appendix B

HDL Checking - Worked Examples

 

Although TransEDA's design rule checking tools will operate on various platforms with different types of simulators, the following assumptions have been made in order to simplify the number of steps in this worked example and case study.

… The platform used is Windows, preferably Windows-NT.

If you are using a different platform than the one listed above, please contact TransEDA for an alternative set of instructions on how to run the worked example.

Getting Organized

It is assumed that VN-Check or Verification Navigator with the optional VN-Check module has been installed on your system according to the vendor's instructions; that the environment variables and search paths have been set up and that the software operates correctly. If this is not the case please contact the vendor's technical support department for further assistance before going any further.

Although this exercise makes use of a couple of Verilog source files located on TransEDA's web site at: www.transeda.com/vmm/ you may prefer to substitute your own Verilog or VHDL files.

If you encounter any problems in obtaining the source files please contact TransEDA at the following e-mail address.

vmm@transeda.com

Starting the Rule-Based Checker

Create a working directory (e.g. my-verilog or my-vhdl) on your system and then unpack the set of files that you obtained in the above step into that area. Alternatively, you can copy your own Verilog or VHDL files into this directory.

If you are using VN-Check in a standalone mode it can be invoked by entering the following text string.

C:\my-verilog> vncheck

If you are using VN-Check within the Verification Navigator environment (i.e. as an additional optional module) it can be invoked by entering the following text string and then clicking the button labelled Rule Checker on the main flowchart.

C:\my-verilog> vnavigator

Either of the above actions will bring up a flowchart (as shown in Figure B-1) that shows graphically the major parts of the rule-based checker and how the various parts relate to each other.

The blue colored buttons in the flowchart are organised to guide a user quickly and easily through the following steps.

… Selecting a rule database
… Selecting the source files
… Selecting the run options
… Running the rule-based checker
… Viewing the results
… Editing the source files
Figure B-1

Each of the above steps are described in detail on the following pages.

Selecting a Rule Database

Move the cursor into the main window labelled VN-Check and click the tab labelled Verilog or VHDL to define which HDL design language you want to use. Access to the set of rule databases, that are supplied with VN-Check, is achieved by clicking the second button labelled Select Rule Databases on the flowchart. This will bring up a window where you can select one or more of the supplied rule databases (as shown in Figure B-2 and B-3). For this particular example the RMM.rdb or BestPractices.rdb rule database is probably the best choice to make.

Figure B-2 Figure B-3

Click the OK button once you have made your choice. The next step is to select which source files you want to check against the rule databases that were chosen in the above step.

Selecting the Source Files

Click the third button on the flowchart labelled Select Source Files. This action will bring up a browser window where you can navigate to the directory that contains your source files. If you invoked VN-Check in the working directory where your source files are located then the source files should be immediately visible. If you are using the demonstration Verilog files, that are available at TransEDA's web site, then select the source file labelled verilog-bad.v Although this particular source file will compile and run correctly it does contain a number of coding, style and documentation problems that will be detected by VN-Check. Figures B-4 and B-5 highlights the areas on the GUI (Graphical User Interface) where the source file(s) are selected.

Figure B-4 Figure B-5

Selecting the Run Options

Click the Select Options button - the fourth button on the flowchart. Move the cursor into the main window labelled VN-Check and click the button labelled Run Options to bring up a small window that lists the options available at run-time. For this particular example the options can be left unchecked as shown in Figure B-6. Click the OK button to dismiss the window.

Figure B-6

Running the Rule-Based Checker

Click the Run Rule Checker button - the fifth button on the flowchart to bring up the Analyze Log window. As each file is analyzed a report is generated and sent to this window to show how many violations have been detected by VN-Check. The violations are categorised into coding, style, documentation and naming problems. The window can be closed by clicking the Dismiss button once you have familiarised yourself with the content of the report.

Viewing the Results

Click the View Report button - the sixth button on the flowchart to bring up the Select Report Files window. This action will open up a browser window where you can navigate to the directory that contains your report file. If you invoked VN-Check in the working directory where your source files are located then the report file should be immediately visible. If you have used the demonstration Verilog files, that are available at TransEDA's web site, and providing you have not altered any of the default options for VN-Check you should see a file labelled VN-Check-vl.rpt Highlight this particular file by clicking on its name and then press the OK button. This action will update the two main windows that are labelled Results Navigator and VN-Check with the information as shown in Figure B-7.

Figure B-7

The information displayed in the Results Navigator panel can be expanded by clicking the triangular buttons (as shown in Figure B-8 and B-9) to reveal the violation details for the coding, style, documentation and naming problems.

Figure B-8  and  Figure B-9

In this particular example there are 12 warnings that relate to coding problems that have been violated in the Best Practices rule database.

They are:

… Named Blocks 3
… Non Blocking Assignments With Delay 4
… Parameterized Ranges For Module Ports 1
… Same Size Operands For = = 2
… Synchronous Preset Registers 2

More information about each violation can be obtained by clicking on each line in the Summary Information panel. For example, try clicking on the entry that relates to the Named Blocks violation. Each time you do this the relevant line of code that contains a problem will be highlighted in the VN-Check window. (e.g. line 15, 24 and 32.) At the same time the lower portion of the VN-Check window will display detailed information about each violation. This is shown in Figure B-10.

Figure B-10

The named block violation is probably fairly easy to understand as it refers to a begin and end block that does not contain a name or label next to the begin keyword. Naming a block assists a designer to locate problems during the debugging phase and also makes code more readable and easier to maintain.

Some of the other problems identified by VN-Check relate to:

(a) not having a delay value specified in a non-blocking assignment,
(b) a module port that contains absolute values rather than parameterized values,
(c) mismatch in the width of operands on the left and right side of an assignment,
(d) synchronous presets missing within a register.

As there are a huge number of rules in each rule-database, a designer may require further supportive information in order to understand why a rule has been broken and more importantly how to fix the problem in the HDL source code. A database querying facility is built into VN-Check to enable a user to instantly obtained details about any rule violations. As shown in Figure B-11, this is achieved by clicking the right-hand mouse button over a highlighted rule violation to reveal a drop-down menu.

Figure B-11

Whenever an entry in the drop-down menu is clicked a detailed explanation window is brought up to provide further guidance for the designer.

Editing the Source Files

The last step to be performed, once the violations have been detected, is to edit the original source files and then re-run VN-Check.

There are two ways to invoke VN-Check's in-built editor. The first and most obvious method is to click the button labelled Edit Files on the flowchart. The second method (as shown in Figure B-12) is to move the cursor into the main VN-Check window (where the source code for the file that is currently being analyzed is displayed) and then right-click the mouse button over the line that contains the problem. Either method will invoke a text editor as shown in Figure B-13.

Figure B-12 Figure B-13

If a designer prefers to use a different text editor (e.g. VI or EMACS) then this can be achieved by altering the following parameter in vnavigator.par

gui editor <editor_name>

Please refer to Chapter 3 of VN-Check's on-line manual for details of the range of editors supported and the corresponding syntax to be used in the above command string.

Once you have completed this simple exercise you should be able to use VN-Check to validate your own personal or project related HDL source files.


    TOC PREV NEXT INDEX  
Copyright (c) 2002
Teamwork International and TransEDA Limited
http://www.transeda.com
Voice: (408) 335-1300
Fax: (408) 335-1319
info@transeda.com