Part 1

Introduction
Ordering the MicroBlaze development kit
Installing the Integrated Software Environment (ISE)
Running a board demo test

Part 2

Design object description

Part 3

Setting up the ISE design software
Running the ISE design software

Part 4

Adding Verilog source code
Generating memories using Coregen
Synthesizing the design
Simulating the design (Introduction)

Part 5

Setting up the simulation environment using Mongoose

Part 6

The simulation process
Compiling macro libraries
Compiling the design
Compiling the testbench
Elaborating everything

Part 7

Testbench description

Part 8

Using HAL the HDL analysis and linting tool from Cadence

Part 9

Regression testing using Mongoose

Part 10

Synthesis using timing constraints (Introduction)

Part 11

The Field Programmable Gate Array (FPGA) description

Part 12

Adding synthesis constraints

Part 13

The MicroBlaze soft processor core
Compiling simulation libraries using compedklib

Part 14

Putting everything together
Installing ISE WebPack 9.1i
Installing EDK 9.1i

Part 15

Xilinx Platform Studio XPS
Software Development Kit SDK
Create a new project in XPS
Generate a design report file

Part 16

Create or import an user peripheral
The MHS file
XPS project files
Xilinx IP center

Part 17

Adding the ETC IP
Generate the system netlist using platgen
What happend during the netlist generation
Generate simulation HDL files

Part 18

Putting together a system simulation environment
The simulation database
The cds.lib file
Compiling the ETC IP
Compiling the block RAM
Compiling Verilog wrappers
Compiling VHDL wrappers
Elaborating the design
Warning messages

Part 19

Generating a Verilog testbench

Part 20

Running our first simulation
Adding the DDR SDRAM
Suppressing assert messages in IEEE packages

Part 21

Debugging the simulation testbench
The reset logic

Part 22

Using the XPS software development kit (SDK)
Software development flow
GNU compiler collection (gcc)
Running SDK
Creating a new C appilcation project

Part 23

Simulating program execution in the MicroBlaze processor
Verification strategy
Verification flow
Writing a simple c program
Loading the program
Running an NCSIM simulation
Simulation result
Compile and build the program inside SDK
Generate assembly code and hex code
Make a NCSIM memory load file
Running a simulation

Part 24

System simulations
DDR SDRAM controller
LED displays and push buttons
OPB GPIO registers
Embedded test controller
Debugging the On-Chip Peripheral bus

Part 25

Implementing the hardware platform
User constraints file
Setting up our constraints file
Specify pin constraints
Specify timing constraints
The implementation directory
Start bitstrem generation
Bitstream generation flow
Scriptfile to run XFlow
Bitstream generation result
Configuration of the FPGA
Using the platform cable USB
ML403 evaluation board
ML403 block diagram
Installing cable drivers
Xilinx JTAG tools on Linux without proprietary kernel modules
Setting up the USB cable
iMPACT FPGA configuration tool
Starting iMPACT

Part 26

Using the iMPACT configuration tool
Boundary Scan and JTAG configuration
IEE standard 1149.1 (JTAG)
The identification register
Read IDCODE
Read the FPGA status register
Device configuration
Using Xilinx Platform Studio

Part 27

Pin assignment closure process
PACE Pin and Area Constraint Editor
Running PACE
Topi the Top Code Generator
Topi setup
Using Topi to modify the Xilinx user constraints file
Xilinx Floorplanner
Viewing pin placement
Xilinx PlanAhead

Part 28

Power calculations
XPower
Low power consumption

Part 29

Hardware setup
Software setup
Download and execute a simple program
Download the bitstream
Get program size
Running the program

Part 30

Running demonstration software applications
ML403 Reference Systemson the CD

Part 31

Adding a 16x2 character LCD display
Set address range
Connecting ports
The easy way to add a new block
Configure the IP block
The LCD driver
LCD display timing
8-bit write operation
Programming sequence
Display setup
More reading
Signal wiring on the ML403 board
Adding constraints
Generate netlist
Generate bitstream

Part 32

Writing the "Hello World" program
SDK platform settings
C program build
C header files
The GPIO API definitions
C program examples
Device configuartion in SDK

Part 33

Simulating the LCD driver
C program
Program execution (Waveform plot)
Generating the software libraries and BSPs
GNU compiler tools
Input files
Output files
Output from SDK build process
Display program size

Part 34

Program disassembly
MicroBlaze software reference guide
System memory layout
Reset sequence
ELF file content
Startup files
First stage initialization files
Second stage initialization files

Part 35

Generate simulation HDL files
Simgen
Data2MEM memory tool
ETC_system_sim.bmm
ETC_system_init.vhd
ETC_system_tb.vhd
Modifying the testbench file
Compiling the BRAM initialization file
Compiling the testbench
Simulating program execution

Part 36

The LCD driver (once more)
Editing the user constraints file
Generate new bitstream
Device configuration
Application program
Displaying "Hello World"

Part 37

Debugging our design
Xilinx microprocessor debugger and GNU software debugging tools
Xilinx microprocessor debugger (XMD)
MicroBlaze processor target
MicroBlaze MDM hardware setup
Debug session
Reading registers in MicroBlaze
Load program
Set breakpoint
Remove breakpoint
Display breakpoints
Start program execution
Single step
Stop program execution
Display program code
Getting help
Using XMD in Xilinx Platform Studio

Part 38

Writing software for our embedded system
Writing a software device driver
Software development overview
Device driver programmer guide
Platform specification format reference manual
Microprocessor Driver Definition (MDD)
Libraries and driver generation
Device driver architecture
xparameters.h
Software driver source code
Source code repository
Software device drivers used
SDK project directory
Header source files

Part 39

Fixing our software driver
etc_v2_1_0.tcl
etc_v2_1_0.mdd
Makefile
xetc_g.c
xetc.h
xetc_l.h
Writing an application program
Print statements
Printout from program
Generate HDL simulation files
Generating the BRAM initialization file
Running a simulation

Part 40

Debugging our hardware design
ChipScope Pro
Trying out ChipScope Pro
ChipScope installation

Part 41

Adding an interrupt controller
Finding an interrupt controller
OPB_INTC
Register map
Configuring the interrupt controller
Making connections
Software setup
xparameters.h
xintc_l.h
Generate a software interrupt
Generate a hardware interrupt
MicroBlaze interrupt handling
MicroBlaze interrupt timing

Part 42

Adding a timer
Connect the interrupt signal
OPB Timer/Counter
Register address map
Library generation
Application program
Simulation results

Part 43

Installing a Linux OS
Why using a Linux OS
Embedded Linux OS
µClinux
Finding a linux OS
Choosing a Linux OS
PetaLinux


Part 44

Adding an external memory controller
Generate addresses
Software platform settings
OPB External Memory Controller


Part 45

A computer cache
Enabling MicroBlaze caches
Specify cacheable memory segment
Instruction cache operation
Data cache operation
Xilinx cachelink XCL
Adding the MCH_OPB_DDR_SDRAM controller
Connect IXCL and DXCL
Connecting ports
ETC_system.mhs

Part 46

Installing and running the Linux OS
Disassembly of the Linux kernel
Download the Linux kernel



Top

I have been designing ASICs for more than 15 years. A few years ago I started to realize that there is another player in town and that is the FPGA circuit. With increasing NRE costs and with the long turn-around times, ASIC designs have become high-risk projects. At the same time FPGAs are getting bigger and faster and many companies have therefore decided to only use FPGAs. I also realized that I have to learn how to design using FPGAs, if I were to get any consulting jobs, especially here in Sweden. This is my story of how I hopefully will learn to use FPGAs in my future designs.

Learning-by-doing

John Dewey (1859-1952) was an American philosopher and educator whose writings and teachings have had profound influences on education in the United States. Dewey's philosophy of education, instrumentalism (also called pragmatism), focused on learning-by-doing rather than rote learning and dogmatic instruction, the current practice of his day.
For Dewey, it was vitally important that education should not be the teaching of mere dead fact, but that the skills and knowledge which students learned be integrated fully into their lives as persons, citizens and human beings. Let's practice learning-by-doing.

An interactive meeting place

I have decided to document the learning process in this blog, successes and setbacks. Hopefully it will help the next person to avoid a few pitfalls. A would like the blog to be interactive and not a one-way document. I invite all of you, newbies to professionals to ask questions, make comments and suggestions for subjects you are missing.

Let's get started

The first thing I did was to order a PowerPC and MicroBlaze  development kit DO-ML403-EDK-ISE-USB-EC from Xilinx. The kit includes:

• ML403 Development Platform including the Virtex-4 FX12 FPGA
• Xilinx Embedded Development Kit including Platform Studio Embedded Tool Suite
• Xilinx ISE WebPack FPGA Design Software
• Development Kit Reference CD
• Programming (JTAG) and serial cables.

I ordered the kit from Silica and two days later the guy from UPS knocked on my door and delivered a big package. Christmas comes early this year, bad the present wasn't from Santa Claus. I had to shell out 10K SEK.
In the kit there is also a 25 pages long document with the descriptive title "Getting Started with PowerPC and MicroBlaze Development Kit - Virtex-4 FX 12 Edition". The document reads: The best way to get started with the development kit is by inserting the Embedded Development Kit Reference CD located in box 1 of your kit. Let's do that, but wait. In the next sentence it says "The reference system included in this kit require the use of a computer installed with the following software:

• Integrated Software Environment (ISE) 8.1i, including Service Pack 2
• Xilinx Embedded Development Kit (EDK) 8.1i, including Service Pack 2

Register the software

To begin using the development kit resources, Xilinx Platform Studio (XPS) and Integrated Software Envionment (ISE) we must first obtain installation keys. To do this we find the Product ID stickers on the back of respective software package and navigate to the URL indicated.After we registered both software packages installation keys will be sent to our email address. We are now ready to install the software. To get the latest software versions we will download the software from the Xilinx download page.

Installation

OK. Let's start by installing the required software. The installation is described in the "Quick Start Information" starting on page 10.

To install a Linux version of ISE from the Xilinx web page follow these steps:

1. Open your web browser and goto the Xilinx download page.
2. Look under Design Tools and find ISE WebPack. Click Download.
   
3. If your a new to Xilinx you have to create an account. If you have an account you can just login.
4. Answer the ISE WebPACK survey and click next.
5. In the Xilinx Software Solutions Access Granted page, click Download ISE WebPACK.
6. On the next page select Red Hat Enterprise 3 and 4 WS (32-bit) Webinstall (15MB).
7. Start downloading the file WebPACK_82i_Webinstall.sh
8. When the download has finished open a terminal and move the file to your home directory (or any other directory you prefer).
9. Change the file permissions to make the script executable. <chmod 755 WebPACK_82i_Webinstall.sh>
10. Make sure you are logged in as root. In Ubuntu Linux root login is disabled. Use the command <sudo -i> to become root. Important !!.
    
11. Run the script ./WebPACK_82i_Webinstall.sh
12. Accept the license agrements and specify the installation directory.
    
13. The final download will start.
14. When the installation has finished, the installation program has created an environment variable setup file (settings.csh and settings.sh) in the installation directory.
15. Go to the installation directory and type <source settings.csh> for csh and tcsh shells and <source settings.sh> for bash and sh shells. This file should be included in your .cshrc or .bashrc file and run every time you start a new shell.
    
16. Type ise & to start the program (install_dir/bin/lin/ise).
    

ISE WebPACK is a downloadable solution for FPGA and CPLD design, offering HDL synthesis and simulation, implementation, device fitting, and JTAG programming. ISE WebPACK 8.2i provides the tools and features along with the same design environment as ISE Foundation design tools, providing instant access to the ISE features and functionality at no cost.

The Embedded Development Kit (EDK) bundle is an integrated software solution for designing embedded processing systems. This pre-configured kit includes the Platform Studio tool suite as well as all the documentation and IP that we require for designing Xilinx Platform FPGAs with embedded PowerPC hard processor cores and/or MicroBlaze soft processor cores.

Question 1. Can you mix different versions of ISE and EDK. I have already installed ISE 8.2i. Can I use it together with EDK 8.1i.

Answer 1. No you can not mix different versions of ISE and EDK. I found out the hard way.

Question 2. I will start installing the Windows versions of all programs but I would prefer to run everything in a Linux environment. Is it possible to do that and which Linux distributions are supported. I have Ubuntu Linux installed.

Answer 2. Yes you can use Ubuntu Linux. I am using Ubuntu 7.04 right now and so far everything works like a dream.

The software installation is now finished. The service packs have been added. Now I am ready to for the board setup as described on pages 12-14.
Here comes the first setback. The document says "Connect a null modem serial cable between your PC and the ML403 board". How can you do that when your PC (laptop) doesn't have a serial connection. The solution is to find an USB to serial converter. After searching the Internet I decided to buy the Keyspan USB Serial Adapter. They have software drivers for MAC OS X, Windows and Linux which was important to me. After installing the software driver a COM3 port appeared in the HyperTerminal window. After setting up the HyperTerminal following the instructions in the document I am ready to go. I turn on the main power switch,  no smoke and press the System ACE RST button. The following menu is displayed:

1. Virtex-4 Slide Show
2. Wind River VxWorks Demo
3. MontaVista Linux Demo
4. Web Server Demo - PPC405
5. Web Server Demo - MicroBlaze
6. DCM Phase Shift Demo - MicroBlaze
7. Mentor ATI Nucleus WebServ Demo

I select 6 because that is the only demo that doesn't need an extra hardware setup. The demo starts and prints the result in the HyperTerminal window. It works. I have taken the first step on  my "FPGA design from scratch" road. I never told you that I am running this software in  Windows XP installed under Parallels Desktop on a MacBook.



Acknowledgement

It wouldn't make sense writing a tutorial like this and not using Xilinx's in-depth knowledge about their products found in their web pages, user guides and other documents. I would like to thank Xilinx for allowing me to use images and text from their documents and to link to their web pages. All images copied from Xilinx are marked "(Courtesy of Xilinx)" and text parts starts with "As it says in the Xilinx Documentation:"

Application Notes

Application Notes illustrate how to use a Xilinx product in a specialized way.

Documentation and Literature

Here is a link to the documentation library.

E-Learning

Xilinx provides recorded E-Learning for courses at our convenience. They are available at no charge.

Forums

There are several forums discussing FPGA design. The Xilinx forum is one of them.

Links

Here are more links to information about ASIC & FPGA design.

ML403 Evaluation Platform Demos and Reference Designs

Here is a link to this page.

Newsgroups

comp.arch.fpga is the main newsgroup for FPGA discussions and comp.arch.embedded for embedded design.

Publications

Subscribe for FREE to the new Xcell Journal Digital. Here are links to old XCell magazines.

Search engines

There are a number of dedicated search engines, searching for FPGA information. FPGASeek is one ChipHit is another.

Solution Guides

Looking for a solution. Maybe you find it here.

Support, Answers Database

You may find an answer to your question in the Xilinx support page.

TechXclusives

Xilinx TechXlusives are interesting articles about FPGA design.

Training

Xilinx provides targeted, high-quality education services designed by experts in programmable logic design, and delivered by Xilinx-qualified trainers. They offer instructor-led classes (both in person and online) and recorded e-learning for self-paced training. Some courses are completely free!

Tutorials

To find out more about using Xilinx development tools you can study one or more of the tutorials found in Xilinx tutorial web page.

User Guides

User guides contain usage information about Xilinx products and features.

WebCase

To post a question to Xilinx you should use WebCase.

Just one last thing

We are going to have fun.





This time you are not left alone.


Top   Next

The design object

Now when we have the infrastructure in place it is time to define a design object. The picture shows a simple block diagram of the hardware design I plan to implement in a FPGA.



The design is an embedded test controller (ETC) that will run a JTAG test program stored in the test program memory. The test result will be stored in the test result memory and when the test has finished the result can be read and compared to the expected data. If the test passes a green led will be turned on and if the test fails a red led will light up.  Here is a short discription of all the steps to run a test:

1. The MicroBlaze reads the test program from the program memory and writes it to the test program memory.
2. The MicroBlaze writes to the control register to setup the ETC
3. The MicroBlaze  writes to the control register to start the  test.
4. The test generator executes the test program and generates test data that will be sent through the test configurator to the test object.
5. The test object sends data back that will be recorded by the test recorder and stored in the test result memory.
6. When the test is finished an interrrupt is sent to the MicroBlaze.
7. The MicroBlaze will write to the control register to stop the test.
8. The MicroBlaze will read the test result memory and compare the data to the expected data stored in the program memory.
9. If the recorded data matches the expected data the test has passed.

Memory map

Register/Memory Name	Size	Access	Address
Test Program RAM	1024x32	Write
Test Result RAM	1024x32	Read
Control	32	Read/Write	Baseaddr+0x0
Status	32	Read	Baseaddr+0x4
Execute	32	Read/Write	Baseaddr+0x8
Debug	32	Read	Baseaddr+0xc

Instruction set

The test generator reads instructions from the test program RAM and executes them sequentially. The following instructions have been implemented.

Op code	Description
4'b0000	No operation
4'b0001	Generate test reset 1 (TSTSZ low for x TCK cycles)
4'b0010	Generate test reset 2 (TMS high for x TCK cycles)
4'b0011	Load JTAG instruction register
4'b0100	Load JTAG data register
4'b0101	Load instruction register and data register
4'b0110	Load data register and instruction register
4'b0111	Load data register and pause in pause-dr
4'b1000	Load data register (continue from pause-dr)
4'b1001	Load data register (continue from pause-dr and stop in pause-dr)
4'b1010	Wait in Run-Test-Idle state a number of TCK cycles
4'b1011	Pause in Run-Test-Idle state
4'b1100	End of test

Program example

Here is an example on how to program the ETC. This program reads the identification code from the IDCODE register by loading the IDCODE instruction and shift out the 32 bit identification code.

parameter INSTRUCTION_LENGTH                  = 4;
parameter DATA_LENGTH                         = 32;
parameter IDCODE                              = 4'b0010;
parameter ALL_TDO_DATA                        = 2'b0;
parameter DEVICE_IDCODE                       = 32'h14012049;

SetTdoRecordingMode      (ALL_TDO_DATA);
TestResetKeepingTrstzLow (10);
LoadInstruction          (INSTRUCTION_LENGTH,IDCODE);
SetExpectedData          (INSTRUCTION_LENGTH,4'b0001);
ReadWriteDataRegister    (DATA_LENGTH,32'h0);
SetExpectedData          (DATA_LENGTH,DEVICE_IDCODE);
EndOfTestProgram;

Design language

Most of the design has already been coded in Verilog HDL. What is left to implement are the two memory blocks.

Top  Next  Previous

Now it's time to get to know the Integrated Software Environment (ISE) design software from Xilinx. The first thing I would like to do is to generate the two memories needed. They have to be two-port memories, one port for writing and one port for reading. The size of the memories should be 1024x32 bits. Better start by finding the documentation from Xilinx. This is what the Xílinx design flow looks like.

                                                                                                      (Courtesy of Xilinx)

Let's begin by reading the "ISE Quick Start Tutorial". This is probably the best way to get started. Go to the pdf download page and download and unpack the file qst.zip. The tutorial contains the following sections:

• Getting Started
• Create a New Project
• Create an HDL source
• Design Simulation
• Create Timing Constraints
• Implement Design and Verify Constraints
• Reimplement Design and Verify Pin Locations
• Download Design to the Spartan-3 Demo Board

You can also download an ISE In-depth tutorial.

I will go through the whole design flow and let you know what I experience. The best way to have a question answered is to create a technical support case using the Xilinx WebCase. Let's get going. The first thing to do is to create a new project.

1. For Windows double click the ISE desktop icon . For Linux type <ise &> in a terminal.
   
2. Select File->New Project
3. Enter project name (ETC) and the directory path for the new project
4. Click next
   
5. Fill in all the device properties and software to use
6. Click next
7. I will add all the source code afterwards.
8. Click finish.

Using Parallels Desktop

Xilinx ISE running in Windows XP




Xilinx ISE running in Ubuntu Linux.



Using VMware Fusion

I have switched to VMware Fusion. For more information read How to install Ubuntu 7.04 using VMware Fusion in Mac OS X.



Windows versus Linux

From now on I will use the Linux version whenever I can. I don't like the blue color.

Top  Next  Previous

Add existing code.

In the processes window double-click the Add Existing Source process. In the file browser window find the design directory and mark all files you would like to include. Repeat until all files have been added.

Check syntax

Mark the top file in the source window. In the process window expand the process Synthesis -XST.  Double-click the Check Syntax process to start the syntax check. The result will be displayed in the console window. Correct all syntax errors and when finished continue to the next step.

Generating memory blocks

In our design we need two memories. One memory to store the test program and one memory to record the test result. The memories must be dual-port memories and their size should be 1024x32. We use the same model for both memories. We will use the Xilinx Core Generator program to generate the memory model. Let's start the program: coregen &



Click the Create new project link and follow the instructions. Don't forget to select VHDL or Verilog in the Project Options window. In the function window, open Memories and Storage->Dual Port Block. Click Customize. Specify all the options you need and click Generate to start the memory block generation. When finished there will be a number of files stored in the destination directory. See File Tree Browser display.




The file <etc_dual_port_1024x32_readme.txt> explains the usage of the different files.

File Name	File Usage
etc_dual_port_1024x32.edn	Electronic Data Netlist (EDN) file containing the information required to implement the module in a Xilinx FPGA.
etc_dual_port_1024x32.v	Verilog wrapper file provided to suppport functional simulation.
etc_dual_port_1024x32.veo	VEO template file containing code that can be used as a model for instantiating a CORE Generator module in a Verilog design.
etc_dual_port_1024x32.xco	CORE Generator input file containing the parameters used to regenerate a core.

We will use the file <etc_dual_port_1024x32.v> in our functional simulations. When we synthesize the design this file will be black boxed. The EDN file <etc_dual_port_1024x32.edn> will be used during the build process to generate the final FPGA design.

Synthesizing the design

Now when the whole design is completed I will do a quick synthesis run to find out if there are any design errors left. I will use the Xilinx synthesis tool XST.

1. Select the top module in the source window
2. Double click the Synthesize - XST tab in the process window.
3. Wait for the synthesis to finish.
4. Read the errors and warnings in the console window
5. Fix the errors and rerun the synthesis.
   
6. When it runs clean you can find out the device utilization from project status report.
7. To see the synthesized netlist double-click View RTL Schematic (see screenshot).
   

Simulating the design

To verify that the design is functionally correct we will use functional verification by the means of logic simulation.  The following standards are supported in the Xilinx simulation flow:

Description	Version
VHDL Language	IEEE-STD-1076-1993
VITAL Modeling Standard	IEEE-STD-1076.4-2000
Verilog Language	IEEE-STD-1364-2001
Standard Delay Format	OVI 3.0
Std_logic Data Type	IEEE-STD-1164-93

Xilinx supports the following simulators:

Simulator	OS	Cost
Xilinx ISE Simulator Lite	Windows	Free
Xilinx ISE Simulator	Windows	Low
Mentor ModelSim XE-III Starter	Windows	Free
Mentor ModelSim XE-III	Windows	Low
Mentor ModelSim PE (Personal Edition)	Windows	Medium
Mentor ModelSim LE (Linux Edition)	Linux	Medium
Mentor ModelSim SE (Special Edition)	Windows, Linux, Unix	High
Cadence Incisive HDL Simulator	Windows, Linux, Unix	High
Synopsys VCS-MX	Linux,Unix	High

The limits for the ISE Simulator Lite are similar to the MXE-III Starter, 10,000 lines of debuggable code. Beyond this limit, the processing begins to slow down, but does not stop. The usefulness of this software is going to depend on coding style and type of simulation (either functional or timing) that is desired.

From this table you can see that there are no free simulators for Linux. It seems I have to go back to Windows or I will ask Cadence for a new evaluation license.

Here is the Xilinx simulation flow. Xilinx supports functional and timing simulations of HDL designs at five points in the HDL design flow:

• Register Transfer Level (RTL)
• Post-Synthesis (Pre-NGDBuild) Gate-Level
• Post-HGDBuild (Pre-Map) Gate-Level
• Post-Map Partial Timing (Block Delays)
• Timing Simulations Post-Place and Route
  

                                                                                                   (Courtesy of Xilinx)

Top  Next  Previous

I have decided to use the Cadence Incisive HDL simulator for my functional verification. I will setup my own simulation environment using a tool called Mongoose. Mongoose is a graphical user interface (GUI) program, designed  for setting up and running a simulation testbench. It can be used as an interactive tool or used for running regression testing in batch mode.
I started to develop the Mongoose program more than 10 years ago and have been using it in all my ASIC verification work. It can be setup to utilize any Verilog or VHDL simulator and it can also integrate Specman for automatic generation of functional tests. In this chapter I will describe how to setup and use the Cadence Insisive HDL simulator in the Mongoose Simulation Environment. Read more about Mongoose in the Zoo Design Platform presentation.

Setting up the simulation environment

Before starting Mongoose we have create a working directory. The working directory is the directory from where we start all our simulations:
mkdir /home/svenand/root/projects/ETC/verification
We don't want to remember this long file name so we will define an environment variable instead:
setenv ETC_VERIFICATION  /home/svenand/root/projects/ETC/verification (csh and tcsh)
Add this statement to your .cshrc file
export ETC_VERIFICATION=/home/svenand/root/projects/ETC/verification (sh and bash)
Add this statement  to your .bashrc file
Go to the working directory: cd $ETC_VERIFICATION
and start the Mongoose program: mongoose &



Open the terminal window by clicking the button.




Next thing to do is to create the file structure needed to support all activities during the simulation phase. Select Create Environment from the Setup menu and fill in the information:

• Design name : ETC
• Environment Variable Name : ETC_VERIFICATION
• Working Directory : $ETC_VERIFICATION
• Language : Verilog
• Simulator : NC-SIM (Incisive HDL Simulator)
• Simulation Setup : Functional
• Script File : $ETC_VERIFICATION/CreateEnvironment
  

Click the Setup Script button to generate and run the environment setup script. When finished click the Mongoose Setup button to save the whole Mongoose setup in the file .mongoose-setup stored in the working directory. The next time you start Mongoose the setup file will be read and your are back to where you were the last time.


Too see what the file structure looks like open the File Tree Browser and click the Set Root button to display the first level of files. Double-click on a directory to see the next level of files.




This table explains the usage of the different directories. This is only a recommendation, you can change almost everything if you like to.

Directory	Description
bookmark	Stores the directory bookmark file
command	Stores saved commands
database	Stores the compiled simulation libraries
debug	Stores debug commands for interactive debugging
design	Stores the verilog or VHDL design files
designDefine	Stores design definition files (behaviour, RTL, netlist)
help	Stores help information
input	Stores TCL input files to the simulator
key	Stores the key file from the simulation
libraryDefine	Stores macro library definition files
log	Stores log files
macrolib	Stores the macro library files
mongoose	Stores all the script files generated from Mongoose
plot	Stores Simvision waveform viewer plot files
result	Stores different result files from the simulation
script	Stores auxilary script files
sdfSetup	Stores sdf setup files
setup	Stores Mongoose setup files
simSetup	Stores simulator setup files (cds.lib, hdl.var)
task	Stores Verilog task files
testbench	Stores Verilog testbench file
testcase	Stores Verilog testcase files

To display the current directories setup open Setup->Environment.




Top Next  Previous

Now when we have the simulation environment in place it is time to start looking at the simulation process using the Cadence Incisive HDL simulator.

The simulation process

It was easier before when we were using Verilog-XL. Just write one input script file including all design files, all macro library files and all testbench files and start Verilog using that file. The simulation kicked-off and when it finished there was a logfile to read. When using the Incisive HDL simulator it is a little bit more complicated. The simulation process is now a three step process including the following steps:

1. Compilation of all design files, macro library files and testbench files.
2. Elaboration of the whole design and saving the result in a snapshot.
3. Simulation of the snapshot.

In the compilation phase all source files will be compiled in to one or more libraries and stored as binary data. It is a good idea to use several libraries and compile the macro library files into one library, the design files into another library and the testbench into yet another library. In this way it is easy to modify the testbench without affecting the rest of the compiled data. In Mongoose we will use this scheme. All files are compiled as induvidual files and there is no control of interconnects between modules.

In the elaboration phase all the libraries are read and elaborated, which means that all depencies are checked. Missing modules, missing connection and unconnected inputs and outputs will be reported. During the elaboration a new database will be built containing the whole design and the testbench connected together. This database can be saved in a snapshot file or it will reside in the testbench library database.

In the simulation phase the snapshot file will be read and the simulation will start executing the simulation flow described in the testbench. Data will be written to a logfile and if enabled there will be a waveform file generated.

Here is a flow diagram showing the simulation process in Mongoose.


This is what the default Incisive HDL simulator setup looks like in Mongoose



The mapping of library names to physical file locations are done in the cds.lib file which must be referenced in the ncvlog compile script. When starting a compilation in Mongoose the mapping shown above will be written to the cds.lib file. The file will look like this:

softinclude $CDS_INST_DIR/tools/inca/files/cds.lib
define macrolib         /home/svenand/root/projects/ETC/verification/database/ncsim/macrolib
define design            /home/svenand/root/projects/ETC/verification/database/ncsim/design
define testbench      /home/svenand/root/projects/ETC/verification/database/ncsim/testbench

Before we can start compiling the source code we need to setup definition files containing all files we are going to compile. Let's start with the macro library files from Xilinx. If you browse through the Xilinx installation you will find the macro libraries here:



We will use the script generator built in to Mongoose to generate the definition files. The Unisims library (having unit delays) and the CoreLib library will be used for our functional simulations.



Now we are ready to compile the macro libraries. Select Macro Library Def from the Object menu. Select one of the definition files and click the start button (the Mongoose).



The compilation will run in the terminal window:




In the same way we compile the design files and the testbench files. The database directory will contain the following files after the compilation phase is finished. The design-info file is added by the Mongoose and includes information about the source files compiled. When Clearcase revision handling is used this file also includes the config spec.



Congratulations, we have all our source code compiled. Time to start elaboration. Just one more thing we have to do before we start, enter the name of the top module (the testbench). We do that in the NCSIM setup window. In our case it is ETC_TEST.



Select IUS/Elaboration and start the elaboration phase. This is what to output looks like:

/home/svenand/root/projects/ETC/verification/.mongoose-batch0
ncelab: 05.83-p003: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
    Elaborating the design hierarchy:
        Caching library 'testbench' ....... Done
        Caching library 'std' ....... Done
        Caching library 'synopsys' ....... Done
        Caching library 'ieee' ....... Done
        Caching library 'ambit' ....... Done
        Caching library 'vital_memory' ....... Done
        Caching library 'ncutils' ....... Done
        Caching library 'ncinternal' ....... Done
        Caching library 'ncmodels' ....... Done
        Caching library 'cds_assertions' ....... Done
        Caching library 'sdilib' ....... Done
        Caching library 'macrolib' ....... Done
        Caching library 'design' ....... Done
 
    Building instance overlay tables: .................... Done
    Loading native compiled code:     .................... Done
    Building instance specific data structures.
    Design hierarchy summary:
                                            Instances  Unique
        Modules:                        4348      87
        UDPs:                              2208       6
        Primitives:                     2710       9
        Timing outputs:           2220      35
        Registers:                     1014     462
        Scalar wires:                2995       -
        Vectored wires:               37       -
        Always blocks:                 98      64
        Initial blocks:                    10       7
        Cont. assignments:         50     194
        Pseudo assignments:       5       5
        Timing checks:            7984     811
        Simulation timescale:   1ps
    Writing initial simulation snapshot: testbench.ETC_TEST:module

We are ready to start the simulation. We only need a IUS license file from Cadence.

Top Next  Previous

Yieppie! I got a 45 days evaluation license from Cadence. Time to start the simulator. But before we do let's take a look at the testbench.

Testbench design

A clean and well-structured testbench is probably the best investment you can do in an ASIC/FPGA design project. Before the verification phases is finished the testbench has been changed hundreds of times. A lot of time will be saved if you find everything quickly in the testbench. There are many ways to setup a verification testbench and it can be more or less complicated. It can include co-simulation with software using c or c++ code, it can include Specman or Vera code and it can be written in SystemVerilog or SystemC. In this example I will describe a typical Verilog testbench without any extras.





Here is a block diagram showing the Verilog testbench I use in this project. It consists of a Verilog testbench body and a Verilog testcase. The Verilog testbench body will include a number of support files during compilation, using the include statement. During compilation the body file and all the include files together with the testcase will will be compiled into one complete testbench. In a ASIC/FPGA project there can be several hundreds of testcases used. Not having to include the testbench body in every testcase will save a lot of disk space.
Let's take a look at the different blocks.

Verilog Testbench Body

The body file contains all the common setup that are used by all testcases. This is what's in the body file:

• Header information
  
• Update and revision information
• Testbench description
• Timescale directive
• Module definition
• Version
• Parameter definitions
• Timing setup
• Integer definitions
• Register definitions
• Probes into the design
• Include statements to include external files
• Initialization routine
• Open output files
• Common counters
• Clock generation

Verilog Testcase

The testcase is made up of a number of simulation tasks that will perform different actions on the device under simulation (DUS). The testcase has the endmodule statement as the last line.

Task Files

I use tasks as much as possible. Tasks make the testcase easier to read and understand. When an error is found in a testcase you only have to fix one task instead of having to change all testcases. All tasks are collected in one or more task files.

Setup Files

The Embedded Test Controller can operate in 5 different modes. For every mode of operation there is a separate setup. These setups are stored in different files and the rigth setup file is included during compilation using an `ìfdef statement. The setup files are generated by the Topi Top Code Generator. Read more about Topi in Zoo Design Platform.

Mongoose Setup

Mongoose supports this testbench setup in several ways. First you specify the testbench body file in the Design Specification window.



To specify where to look for include files you use the compile command -incdir. You can specify up to four include directories in the Verilog Simulation Setup window.



We put all our testbench files here:



Now when we have a better understanding of the testbench let's start the simulation. Start Mongoose and select Testcase (Verilog) from the Object menu.



Select one of the testcases and click the start button. Mongoose is setup to run a three step process, compiling, elaborating and simulating in one pass. You can choose to run compilation, elaboration and simulation as separate steps if you prefer.

Debugging the design

There are many ways to debug the design and the testbench. The best debugging tool I know about is the Simvision waveform viewer, which is included in the Incisive HDL simulator. When debugging the design, I enable the generation of a waveform dump, run the full simulation or as long as I need, then load the dump file into Simvision and start tracing the problem. To setup a waveform dump in Mongoose use the Waveform Dump window. The ### specification in the file name will automatically be replaced by the testcase name. You enable the generation of a dump file by setting the Dump flag to sst/wlf.




Debugging tips

For a huge design the dump file can be several gigabytes if not limited. There are several ways to limit the size of the dump file.

• Set the scope depth to only dump down to a certain hierarchical level. Default is 0 (= all levels).
  
• Only dump certain parts of the design by entering one or two scope names.
• Set the dump file size to the maximum size you can handle.

Simulation result

When the simulation has finished we open Simvision using the command: simvision <dump_file> The first window displayed is the Design Browser. Select the signals you would like to look at and click the Waveform display button.



Here is a waveform plot of the working design.



We will probably open simvision many times during the verification phase. Let's define a user button to open it.

Mongoose User Defined Buttons

Open the User Buttons window in the Setup menu. Choose a name for the first button (SImvision) and enter the command executed when clicking the button. We will define the following command: simvision $PLOT_FIILE &. <$PLOT_FILE> reference the latest dump file generated. Click the update button and the user defined button will appear in the terminal window. In the same way you can define three more buttons.



This is what the terminal window looks like.




We are done with the design

Congratulations! We have I working solution. We have run all the testcases and they pass. Now is time to figure out how to get this design into an FPGA. That is the subject of the next chapter in this story.

Top Next  Previous

Before we start synthesizing the design, let's make sure we have a clean design that won't give us any problems. We will use the HDL Analysis and Lint (HAL) tool  from Cadence to check our design. There are other tools available like, Spyglass from Atrenta, Indigo RTL Analysis from Blue Perl Software and Leda from Synopsys. We will use HAL because it is an efficient tool and it is part of the Incisive HDL simulator toolbox.

Using HAL

The first thing we will do is to read the HAL user guide to find out more about the program.
To open the user guide execute the following command: xpdf /cadence_install_dir/doc/hal/hal.pdf &
I have problems using the Cadence documentation system cdsdoc. I much prefer to read the pdf files using a standard PDF viewer like xpdf. To read the HAL reference manual use the following command: xpdf /cadence_install_dir/doc/halref/halref.pdf &

Introduction

This text is taken from the HAL user guide: "Functional closure in the ever-shrinking design cycles is achievable only by catching issues as early and as rapidly as possible. Design verification engineers need detection of problems related to multiple phases of design cycle, while the design is still under development at the RTL level. Such early warnings are a key to avoiding the expensive design iterations, and meeting quality and time-to-market goals. HAL checks the design for:

• Design consistency, reusability and portability
• Semantic correctness
• Synthesizability
• Testability and more"

Beautiful words let's see how good it is in reality. The flow diagram shows the two ways you can use HAL. The snapshot-based flow and the source file-based flow. We will use the snapshot-based flow.


Here is the complete HAL flow:

1. Compile the design blocks into a library (design)
2. Elaborate the design and save the result in a snapshot file (ETC_snapshot)
3. Start hal using the following command: hal  design.ETC_snapshot
4. HAL will execute and the result will be stored in a log file: hal.log
5. To analyze the result start ncbrowse using the following command: ncbrowse -sortby severity -sortby category -sortby tag hal.log
   

We can use Mongoose (see Zoo Design Platform) to run the HDL analysis using HAL. But before we do let's save the current setup using the Load/Save Setup window.



We will save the current setup in the file ETC_simulation.setup and then create a new setup called ETC_analysis.setup to be used during the HAL runs. When we want to return to the simulation setup we will load ETC_simulation.setup and everything in Mongoose will be restored. This way we can handle a new task in Mongoose without interfering with other tasks.

This time we will only elaborate the design files and exclude the testbench. Let's change the top entity to ETC and give a name to the snapshot file : ETC_snapshot.



Select IUS/Elaboration from the Tool menu and start the elaboration:

ncelab: 05.83-p003: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
    Elaborating the design hierarchy:
        Caching library 'design' ....... Done
        Caching library 'std' ....... Done
        Caching library 'synopsys' ....... Done
        Caching library 'ieee' ....... Done
        Caching library 'ambit' ....... Done
        Caching library 'vital_memory' ....... Done
        Caching library 'ncutils' ....... Done
        Caching library 'ncinternal' ....... Done
        Caching library 'ncmodels' ....... Done
        Caching library 'cds_assertions' ....... Done
        Caching library 'sdilib' ....... Done
        Caching library 'macrolib' ....... Done
    Building instance overlay tables: .................... Done
    Loading native compiled code:     .................... Done
    Building instance specific data structures.
    Design hierarchy summary:
                         Instances  Unique
        Modules:                10       8
        Registers:             340     211
        Scalar wires:          154       -
        Vectored wires:         33       -
        Always blocks:          94      60
        Initial blocks:          6       3
        Cont. assignments:      63      71
        Timing checks:          16       -
        Simulation timescale:  1ps
    Writing initial simulation snapshot: design.ETC_snapshot:module


Select HAL from the Tool menu and start the HAL run.



hal: 05.83-p003: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
Incisive HDL analysis
hal: Options:   design.ETC_snapshot:module.
hal: Snapshot:  design.ETC_snapshot:module.
hal: Workspace: /home/svenand/root/projects/ETC/verification.
hal: Date: Sat Jan 13 00:16:31 CET 2007.

Performing lint checks
....................
Performing synthesizability checks
.
Analysis summary :

 Errors   : (2)
 METAEQ (2)    

 Warnings : (2082)
  BADSYS (24)     BITUSD (6)      CDEFCV (7)      CNSTLT (152)  
  CONSTC (44)     CTLCHR (404)    DIRRNG (9)      FNAVPC (5)    
  IGNDLY (4)      IMPTYP (91)     INIMEM (5)      INPASN (2)    
  INTTOB (16)     LCVARN (206)    LEXPGM (1)      MAXLEN (193)  
  MEMSIZ (2)      METACO (2)      MPCMPE (9)      MULOPR (16)   
  NEQPRM (33)     NESTIF (1)      NETDCL (20)     NOBLKN (49)   
  NOSPEC (1)      NOTECH (1)      OBMEMI (8)      POIASG (60)   
  PRMNAM (1)      PRMSZM (6)      SEPLIN (274)    STYVAL (110)  
  SYNTXZ (26)     UCCONN (150)    UELASG (34)     UELOPR (24)   
  ULRELE (33)     UNCONN (13)     URAREG (19)     URDPRT (1)    
  URDWIR (4)      USEFTN (3)      USEPAR (10)     VERREP (3)    

 Notes    : (90)
  ALOWID (11)     DECLIN (4)      IDLENG (75)   

Analysis failed.


Oophs! 2 errors and 2082 warnings. That's a lot of errors and warnings. Let's open the NCBrowse tool to analyze what is going on. Use the command: ncbrowse -sortby severity -sortby category -sortby tag hal.log &. Why not add this command to a user defined button. See previous chapter for a description.



A look at the log file reveals that the Xilinx memory is a behavioral verilog model that generates the two errors and many of the warnings we see. We have to exclude the memory from the analysis by adding this code in the design_info file (see HAL User Guide):

bb_list
  {
     designunit = ETC_DUAL_PORT_1024x32;
     file = /home/svenand/root/projects/ETC/design/ETC_DUAL_PORT_1024x32.v;
    
  }
 
This code will blackbox the memory and everything inside the memory block. When we rerun hal with the design_info file included we get the following result:

hal: 05.83-p003: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
Incisive HDL analysis
hal: Options:   -cdslib /home/svenand/root/projects/ETC/verification/simSetup/ncsim/cds.lib -logfile /home/svenand/root/projects/ETC/verification/hal/log/hal.log -File hal/script/etc_hal.script.
hal: Snapshot:  design.ETC_snapshot.
hal: Workspace: /home/svenand/root/projects/ETC/verification.
hal: Date: Sun Jan 14 00:42:26 CET 2007.

Performing lint checks
...........
Performing synthesizability checks
.
Analysis summary :

 Warnings : (821)
  BITUSD (6)      CDEFCV (7)      CNSTLT (36)     CTLCHR (77)   
  DIRRNG (8)      IMPTYP (25)     LCVARN (182)    MAXLEN (103)  
  MPCMPE (1)      NESTIF (1)      NETDCL (20)     NOBLKN (12)   
  POIASG (25)     SEPLIN (127)    STYVAL (97)     UCCONN (93)   
  URDPRT (1)    

 Notes    : (73)
  ALOWID (11)     IDLENG (62)   

Analysis failed.


We have go through the remaining warnings and see which ones can be ignored and which ones we have to investigate further.

Warning	Description	Comment	Ignored
BITUSD	Unused bits inside a always block		No
CDEFCV	Redundant default clause used		No
CNSTLT	Literal '3'b1' should be replaced with a constant		Yes
CTLCHR	Control characters in the source code found (tabs)		Yes
DIRRNG	Inconsistent ordering of bits [0:31]	OPB bus swapped	Yes
IMPTYP	Implicit type conversion		No
LCVARN	Uppercase characters used for names	I prefer upper case	Yes
MAXLEN	Lines too long (more than 80 charcters)		Yes
MPCMPE	Complex expressions, should add parentheses		No
NESTIF	A nested if, in which the same variable is used in if comparisons, has been detected		No
NETDCL	Declarations made prior to non-declarative statements	I will move the parameter statements	No
NOBLKN	Always blocks not labeled		Yes
POIASG	Overflow not verified	Counters will always wrap-around	Yes
SEPLIN	Use a separate line for each HDL statement		Yes
STYVAL	Numeric value used for identifier		Yes
UCCONN	Lowercase characters used for identifier		Yes
URDPRT	Unconnected port		No

HAL setup window:




After disabling the warnings we decided to ignore, here is the final result. I will take a closer look at these warnings and make the changes needed to get the design to pass HDL analysis.
We are then ready for the final synthesis run.


hal: 05.83-p003: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
Incisive HDL analysis
hal: Options:   -cdslib /home/svenand/root/projects/ETC/verification/simSetup/ncsim/cds.lib -logfile /home/svenand/root/projects/ETC/verification/analysis/log/hal.log -File /home/svenand/root/projects/ETC/verification/analysis/script/etc_hal.script.
hal: Snapshot:  design.ETC_snapshot.
hal: Workspace: /home/svenand/root/projects/ETC/verification.
hal: Date: Mon Jan 15 10:06:44 CET 2007.

Performing lint checks
...
Performing synthesizability checks
.
Analysis summary :

 Warnings : (61)
  BITUSD (6)      CDEFCV (7)      IMPTYP (25)     MPCMPE (1)    
  NESTIF (1)      NETDCL (20)     URDPRT (1)    

 Notes    : (73)
  ALOWID (11)     IDLENG (62)   

Analysis failed.

Top Next  Previous

When we have a stable design it is time to start the regression testing. We have to put together a test suite containing all the testcases we would like to use for our functional simulation. When we run all these testcases we will produce a lot of test result log files. We need a system to handle the whole regression testing and the Mongoose Simulation Environment can help you.

Regression Testing in Mongoose

Mongoose uses test sequences written in the Mongoose Script Language (MSL) to perform regression testing. A  test sequence is a collection of testcases that are executed in sequence. You can control when to start a new testcase and where to send it. It can run as a background job on your own host or it can be sent to a batch queue manager (LSF) and  run on a dedicated simulation host.
This flow diagram shows the process of generating a test sequence, running a test sequence, analyzing the result and display the result in a web browser and/or send an email or SMS with a summary of all test results.



Here is an example of a test sequence file. You can mix unix commands and Mongoose script commands. Lines starting with UC: are a unix commands and lines starting with MC: are Mongoose commands. You can write this file by hand or you can use the Test Sequence Generator to automatically generate one from the testcases you selected.


//$$HEADER
/*************************************************************************/
// Module:        ETC_TEST
// Design:        ETC
// Written by:    Sven-Ake Andersson ZooCad Consulting
// Description:   Test sequence file used for regression runs 
/*************************************************************************/

UC:echo 'Start test sequence'
MC:DisplayTime
MC:ClearAllCounters
MC:ClearFileNameAddOns
MC:AddTestCountToFileName
MC:AddTagNameToFileName
MC:SaveTickerInfo
MC:StartTicker
MC:SetTestCounter 1
MC:SetTagName ETC
MC:SetReportFormatShort
MC:SelectLogFile On
MC:SetReleaseName today
// Start of test sequence
UC:echo 'Testcase running : AllInstructionsExternalExcl.tc'
1:AllInstructionsExternalExcl.tc
MC:WaitSeconds 20
MC:WaitForSimulationToFinish 100
UC:echo 'Testcase running : BypassExternalExcl.tc'
1:BypassExternalExcl.tc
MC:WaitSeconds 20
MC:WaitForSimulationToFinish 100
// Add more testcases here
// ..................
MC:GenerateErrorReport
MC:DisplayHtmlFile
// Stop routine
UC:echo 'End of test sequence'
MC:SendErrorCount
MC:SendSMS 0706420380
MC:SendEmail zoodesign@comhem.se
MC:DisplayTime
MC:EndOfTestSequence


This is the email and SMS message sender window.



After running our testcases we have all simulation log files saved in the result/printout directory:



Let's use the Log File Analyzer/Test Report Generator to generate a condensed test report file.



The Test Report Generator will search all log files for important information and put it into the report file. The two errors reported are from testcases testing a function not implemented and can be ignored. We are finally ready for implementing the design into the FPGA.

Here is the email sent from the Mongoose script:




Top Next  Previous