New Horizons

Welcome to my blog

My name is Sven Andersson and I
work as a consultant in embedded
system design, implemented in ASIC
and FPGA.
In my spare time I write this blog
and I hope it will inspire others to
learn more about this fantastic field.
I live in Stockholm Sweden and have
my own company


You are welcome to contact me
and ask questions or make comments
about my blog.


New Horizons
What's new
Starting a blog
Writing a blog
Using an RSS reader

Zynq Design From Scratch
Started February 2014
1 Introduction
Changes and updates
2 Zynq-7000 All Programmable SoC
3 ZedBoard and other boards
4 Computer platform and VirtualBox
5 Installing Ubuntu
6 Fixing Ubuntu
7 Installing Vivado
8 Starting Vivado
9 Using Vivado
10 Lab 1. Create a Zynq project
11 Lab 1. Build a hardware platform
12 Lab 1. Create a software application
13 Lab 1. Connect to ZedBoard
14 Lab 1. Run a software application
15 Lab 1. Benchmarking ARM Cortex-A9
16 Lab 2. Adding a GPIO peripheral
17 Lab 2. Create a custom HDL module
18 Lab 2. Connect package pins and implement
19 Lab 2. Create a software application and configure the PL
20 Lab 2. Debugging a software application
21 Running Linux from SD card
22 Installing PetaLinux
23 Booting PetaLinux
24 Connect to ZedBoad via ethernet
25 Rebuilding the PetaLinux kernel image
26 Running a DHCP server on the host
27 Running a TFTP server on the host
28 PetaLinux boot via U-boot
29 PetaLinux application development
30 Fixing the host computer
31 Running NFS servers
32 VirtualBox seamless mode
33 Mounting guest file system using sshfs
34 PetaLinux. Setting up a web server
35 PetaLinux. Using cgi scripts
36 PetaLinux. Web enabled application
37 Convert from VirtualBox to VMware
38 Running Linaro Ubuntu on ZedBoard
39 Running Android on ZedBoard
40 Lab2. Booting from SD card and SPI flash
41 Lab2. PetaLinux board bringup
42 Lab2. Writing userspace IO device driver
43 Lab2. Hardware debugging
44 MicroZed quick start
45 Installing Vivado 2014.1
46 Lab3. Adding push buttons to our Zynq system
47 Lab3. Adding an interrupt service routine
48 Installing Ubuntu 14.04
49 Installing Vivado and Petalinux 2014.2
50 Using Vivado 2014.2
51 Upgrading to Ubuntu 14.04
52 Using Petalinux 2014.2
53 Booting from SD card and SPI flash
54 Booting Petalinux 2014.2 from SD card
55 Booting Petalinux 2014.2 from SPI flash
56 Installing Vivado 2014.3

Chipotle Verification System

EE Times Retrospective Series
It all started more than 40 years ago
My first job as an electrical engineer
The Memory (R)evolution
The Microprocessor (R)evolution

Four soft-core processors
Started January 2012
Table of contents
OpenRISC 1200
Nios II

Using the Spartan-6 LX9 MicroBoard
Started August 2011
Table of contents
Problems, fixes and solutions

FPGA Design From Scratch
Started December 2006
Table of contents
Acronyms and abbreviations

Actel FPGA design
Designing with an Actel FPGA. Part 1
Designing with an Actel FPGA. Part 2
Designing with an Actel FPGA. Part 3
Designing with an Actel FPGA. Part 4
Designing with an Actel FPGA. Part 5

A hardware designer's best friend
Zoo Design Platform

Installing Cobra Command Tool
A processor benchmark

Porting a Unix program to Mac OS X
Fixing a HyperTerminal in Mac OS X
A dream come true

Stockholm by bike

The New York City Marathon

Kittelfjall Lappland

Tour skating in Sweden and around the world
Wild skating
Tour day
Safety equipment
A look at the equipment you need
Skate maintenance
Books, photos, films and videos
Weather forecasts

38000 feet above see level
A trip to Spain
Florida the sunshine state

Photo Albums
Seaside Florida
Ronda Spain
Sevilla Spain
Cordoba Spain
Alhambra Spain
KittelfjÀll Lapland
Landsort Art Walk
Skating on thin ice

100 Power Tips for FPGA Designers

Adventures in ASIC
Computer History Museum
Design & Reuse
d9 Tech Blog
EDA Cafe
EDA DesignLine
Eli's tech Blog
FPGA Arcade
FPGA Central
FPGA developer
FPGA Journal
FPGA World
Lesley Shannon Courses
Mac 2 Ubuntu
Programmable Logic DesignLine
World of ASIC

If you want to be updated on this weblog Enter your email here:

rss feed

Wednesday, December 13, 2006
FPGA design from scratch. Part 7
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

Posted at 07:41 by


Leave a Comment:


Homepage (optional)


Previous Entry Home Next Entry