Icarus Verilog

SIMBUS User Guide

48pages on
this wiki
Add New Page
Talk0 Share

SIMBUS is an add-on to Icarus Verilog that allows distributed simulations of systems connected by a bus of some sort. The basic idea is that you break your simulation into separate devices that are attached to a bus. For example, if your system is a collection of devices attached by a PCI bus, you divide out each pci device into its own simulation and leave SIMBUS to act as the glue that connects your system together.

How it Works Edit

The core of SIMBUS is the simbus server, which receives state from the clients and redistributes merged state back out. Depending on the bus protocol, the server has some minimal understanding of the protocol, and may even provide some of the signals. For example, for PCI, the server generates the PCI clock, and performs arbitration using the REQ# and GNT# pci signals. The server also does basic PCI interrupt routing.

To make an entire system work, you must compile your DUT with the bus bindings, write your test bench in C/C++, and write a server configuration that links all the parts together.

Connecting Verilog Via PCI Edit

Your device under test is written in Verilog, and has a PCI interface. All you need to do it create a top-level module that instantiates your DUT, and instantiates an instance of the pci_slot module that comes with SIMBUS. Connect all your DUT PCI pins to the matching pins on the pci_slot instance. That's it. Compile the top level module (that includes the pci_slot and your DUT) and you are ready to connect your design to a PCI system.

The pci_slot module handles all the communication with the server. It will use the name that you passed (by overriding its "name" parameter) to connect to the server, and the server will use the name to bind it into the PCI bus.

The PCI C/C++ API Edit


Server Configuration Edit

The top level description of a simulation is the server configuration file. This file describes to the server all the busses in your system; the device attach points, and the programs used to implement the devices. The server configuration can be a single complete file, or can be spread into a set of files.

General Syntax Edit

Server configuration files are ASCII text files. Comments start with the "#" character and continue to the end of the line. The syntax includes keywords (which are described below) as well as numbers, strings and words. Numbers are one or more decimal digits. Strings are arbitrary strings surrounded by double-quote characters, and words are any words made up of upper or lower case letters, digits, and underscore characters.

# This is a comment.

# Here, "name" is a keyword, and "main bus" is a string.
name = "main bus" ;

# In this case, CLOCK_high is a word (not a keyword) and
# "2000" is a number.
CLOCK_high = 2000;

Bus descriptions Edit

All the busses in a system are fully described by their bus descriptions. The description names the bus, assigns a bus protocol, describes the bus service port and enumerates all the bus clients. A bus description may also describe bus parameters, if the protocol supports them. Each bus description describes exactly one bus, although the server may be configured with multiple busses.

A bus description starts with the keyword "bus" and an open curly brace "{", and is closed by a close curly brace "}". A bus description must be complete within a server configuration file. The bus description collects the bus description items for a single bus. Each bus in the system must have its own bus description within a server configuration file.

bus {
   # Comments start with the "#" character
   # and continue to the end of the line.
   [...bus description items...]

Most bus description items have the form "<keyword> = <value>;". All bus description items are terminated by a semi-colon ";" character.

Process descriptions Edit

A typical simulation consists of a variety of devices attached to a collection of busses. This could lead to many processes to be started by hand. Although the server supports leaving process startup to the user, sometimes it is too much and we want the server to start processes for us. The process description describes programs that the server should start for us. It includes the command line (script) to execute programs, redirects for program output, and a means to set program environment.

This is an optional convenience. It doesn't have to be complete, or even used at all. If a simulation is to be spread across multiple machines (using TCP network ports to connect devices) it will likely be necessary to use external methods to start the programs.

A process description starts with the keyword "process" and an open curly brace "{", and is closed by a close curly brace "}". A process description must be complete within a server configuration file. A process description describes a single process, so there is a process description for each process that the server manages.

process {
   # Comments start with the "#" character
   # and continue to the end of the line.
   [...process description items...]

All process description items have the form "<keyword> = <value>" and are terminated by a semi-colon ";" character.

Keyword List Edit

This is an alphabetical list of the keywords in server configuration files. This list may grow from time to time as the Simbus package is expanded.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.