Introduction

This help file is part of the SMT6500 package and provides information about using the FPGA on the Sundance TIMs (Texas Instruments Module). The ADC, DAC, DAQ are not discussed here.

The SMT6500 comprises:

  • The Sundance FPGA core library

  • The firmware for Sundance modules

  • The software library to configure the FPGA

  • Sample projects illustrating the use of Sundance firmware

The SMT6500 allows the Hardware Designers to build FPGAs by following the traditional design flow for these devices. Note that Sundance strongly advises the Design Engineers who wish to use the 3L Diamond FPGA design tool to add more flexibility in the design flows


Hardware section

Intended audience

This document gives information for users wishing to develop their own FPGA device with Sundance's cores on FPGA-based modules.

The software examples provided with this package use the 3L Diamond Server, and most hardware design have been synthesized with Xilinx ISE.

We assume that you have read the standard Sundance help file, the SMT6400 help file and are familiar with the following concepts:

  • TIMs (Texas Instruments Modules)

  • Carrier boards

  • Xilinx Virtex FPGAs

  • ComPorts, Sundance Digital Bus, Sundance High-speed Bus, Global Bus and Rocket-IO Serial Link


Hardware section

About this document

This document gives details information about the following Sundance resources:

  • Communication resources:

    • Comport

    • Sundance Digital Bus

    • Rocket-IO Serial Link

    • Global Bus

  • Configuration methodologies of the FPGA

    • Using the JTAG cable

    • Using the on-board DSP

    • Using a comport

    • Using the on-board ROM memory

  • Firmware

    • Model overview

    • Implementation

    • Sundance firmware

    • Design environment

It also includes an example to handle them.


Hardware section

Further information

The following documents give more information about the topics dealt with here:

Sundance Help File | http://www.sundance.com/docs/sundance.chm
SMT6400 help file | http://www.sundance.com/docs/SMT6400.chm
3L Diamond | http://www.3l.com/Diamond/Sundance/diamond_for_sundance.htm
Xilinx website | http://www.xilinx.com


Sundance communication resources

There are several different ways to exchange data between Sundance hardware modules and other peripheral devices.

TIMs allow data exchange by providing a number of different sets of signals, most of which are normally present on processor TIMs; some of them may also be available on other types of TIM. The signals give the following data exchange mechanisms:

  • Communication ports (Comports)

  • Sundance Digital Link (SDL)

  • Sundance Digital Bus (SDB)

  • Sundance High-speed Bus (SHB)

  • Rocket-IO Serial Link (RSL)

  • Global Bus (GBus)

These communication resources are implemented in the FPGA of the module.

We give a brief overview of the communication resources.

Note: A more complete description overview of these communication interfaces is described in the Sundance help file.


Comport

A comport is an asynchronous, 8-bits link. A comport sustains up to 20 MB/s data rate.


Sundance Digital Link

A Sundance Digital Link is similar to a comport. It is a synchronous 8-bit link.

It sustains up to 25 MB/s data rate when it is clocked at 100MHz.


Sundance Digital bus

The Sundance Digital Bus provides a fast communication link between TIMs.

It transmits 16-bit data word at a time, and it allows a data rate up to 200 MB/s.


Sundance High-speed Bus

The Sundance High-speed Bus provides a fast communication link between TIMs.

It transmits 32-bit data word at a time, and it allows a data rate up to 400 MB/s.


Rocket-IO Serial Link

The Rocket Serial Link is a fast serial communication link based on Xilinx Rocket-IO.

The RSL can sustain a data rate of 2.5Gbit/s per lane.

The RSL can be bonded for higher transfer rates (i.e. grouping 4 RSL lanes sustains up to 10Gbit/s).


Global bus

When connected to the PCI bridge of the Sundance carrier boards, it gives access to PCI resources of the host system.

The performances of the Global Bus depends upon the Host PC.


Configuraing the FPGA

Configuring the FPGA

At power-up, the FPGA wakes up with all its pins inactive, and with no functionality. Once the FPGA is configured, it becomes active, performing the logic function programmed into it.

Configuring a FPGA is the process of loading the design data (bitstream) into the device. The function of the FPGA is defined by a user program called the firmware. The firmware is compiled to create the bitstream file that will be used to configure the FPGA. Sundance uses the VHDL programming language to describe the firmware.

The different ways to configure a FPGA will be discussed in this section. The various options available depend on the type of TIM, and on the system architecture.


Using JTAG

It is possible to configure the FPGA by using a JTAG cable and a software running on the PC. You can directly access the FPGA and download the firmware into the device. This is mostly used during the development, and the debug phases.


Requirements

You need a host system running the software Xilinx iMPACT (or an equivalent) with a JTAG cable (Xilinx Parallel Cable IV).


DSP type TIM

On the modules provided with an on-board DSP, the DSP is in charge of configuring the FPGA.

Standard firmwares for these modules are provided by Sundance. See the section Firmware for more details.


Configuring from FLASH

For a DSP TIM, the bitstream (FPGA data) is stored in the flash ROM that populates the module.

The DSP loads a bootloader at power-up or reset.

This bootloader loads the FPGA bitstream from the flash memory on the TIM, and sends the FPGA data to the reconfigurable device to configure it. This process usually takes a few seconds.

You can use the SMT6001 to store the bitstream into the flash ROM.


FPGA type TIM

These TIMs do not have a DSP on-board. The configuration of the FPGA is usually handled by a CPLD or microcontroller.

These modules can be configured from:

  • Host

  • DSP type TIM

  • FLASH device

Note: The FPGA of the FPGA type TIM is uncommitted. There is no standard firmware provided by Sundance for these modules. The Basic communication blocks are available in the firmware section to build a custom firmware.


Configuring from host

Sundance provides a basic bitstream download utility that runs on the host system. This Bitstream load utility can be accessed from this following path: ..\Program Files\Sundance\SMT6500\Software\BitstreamLd\BitstreamLd.exe

This utility uses the host comport to download the configuration bitstream. This mostly means that the TIM has to be plugged onto the TIM site 1 of the Carrier board.

The users can also use the SMT6025 Host SDK to develop their custom Host application to download the bitstream.


Configuring from DSP

In this case, the configuration device is a DSP somewhere else in the system (i.e. onto another TIM of the system).

The DSP provides the configuration bitstream to the FPGA module via a comport. The DSP module typically uses the configuration library provided in this package.


Configuration library

The SMT6500 software library provides a set of functions to configure FPGA-only modules.

Those functions have to be implemented in a software application that will run onto a DSP.

There are different libraries to choose from depending upon the software used:

  • on the DSP side: the DSP application built is a 3L Diamond application, or a Code Composer executable.

  • on the Host side: the DSP application runs with 3L Diamond server, the SMT6025, TI Code Composer Studio or nothing (standalone mode).

The following documents explain the various communications between the host side and the DSP side supported by this software library.

  • With 3L Diamond for a Non-Standalone application

  • With 3L Diamond for a Standalone application

  • Without 3L Diamond


With Diamond - Non-standalone

Config_FPGA.lib is the library to use when you are using 3L Diamond on the DSP in a non-standalone mode.

  • Functions

  • Applications

Functions:

 | ConfigStdioCP
Prototype: | UINT ConfigStdioCP (CCHAR *pcsFile, UINT nCp, UINT keyscheme);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the stdio library to access the bitstream file and can be used when there is a 3L Diamond server or Code Composer Studio running on the host system.

 | ConfigStdioChan
Prototype: | UINT ConfigStdioChan (CCHAR *pcsFile, CHAN *chan, UINT keyscheme);
Parameters: | pcsFile | Name of the bitstream file
 | chan | Selects the channel where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a channel. The function uses the stdio library to access the bitstream file and can be used when there is a 3L Diamond server or Code Composer Studio running on the host system.

 | ConfigHscCP
Prototype: | UINT ConfigHscCP (CCHAR *pcsFile, UINT nCp, UINT keyscheme);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the High Speed Channel library to access the bitstream file and can be used when there is any Sundance software running on the host system.

 | ConfigHscCP_known
Prototype: | UINT ConfigHscCP_known (CCHAR *pcsFile, UINT nCp, UINT keyscheme, SC6xSmtI *p);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
 | p | Pointer to the board services interface.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the High Speed Channel library to access the bitstream file and can be used when there is any Sundance software running on the host system.

 | ConfigMemCP
Prototype: | UINT ConfigMemCP (UCHAR *pcBuf, UINT nBytes, UINT nCp, UINT keyscheme);
Parameters: | pcBuf | Address of the memory where the bitstream is stored.
 | nBytes | Size of the memory where the bitstream is stored
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the DSP memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | ConfigFlashCP
Prototype: | UINT ConfigHscCP (UINT id, UINT nCp, UINT keyscheme);
Parameters: | id | Select the ID of the flash area where the bitstream is stored.
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the flash memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | GetError
Prototype: | CCHAR * GetError(UINT nErr);
Parameters: | nErr | The error code.
Return value: | A string description of the error code.
Notes: | This function converts an error value into a string describing the error.

Applications:

The following diagram describes in which case to use the configuration functions included in this library.


With Diamond - Standalone

Config_FPGA_sa.lib is the library to use when you are using 3L Diamond on the DSP in a non-standalone mode.

  • Functions

  • Applications

Functions:

 | ConfigHscCP
Prototype: | UINT ConfigHscCP (CCHAR *pcsFile, UINT nCp, UINT keyscheme);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the High Speed Channel library to access the bitstream file and can be used when there is any Sundance software running on the host system.

 | ConfigHscCP_known
Prototype: | UINT ConfigHscCP_known (CCHAR *pcsFile, UINT nCp, UINT keyscheme, SC6xSmtI *p);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
 | p | Pointer to the board services interface.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the High Speed Channel library to access the bitstream file and can be used when there is any Sundance software running on the host system.

 | ConfigMemCP
Prototype: | UINT ConfigMemCP (UCHAR *pcBuf, UINT nBytes, UINT nCp, UINT keyscheme);
Parameters: | pcBuf | Address of the memory where the bitstream is stored.
 | nBytes | Size of the memory where the bitstream is stored
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the DSP memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | ConfigFlashCP
Prototype: | UINT ConfigHscCP (UINT id, UINT nCp, UINT keyscheme);
Parameters: | id | Select the ID of the flash area where the bitstream is stored.
 | nCp | Selects the comport where the bitstream should be written out.
 | keyscheme | Selects the startkey / endkey combination to use.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the flash memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | GetError
Prototype: | CCHAR * GetError(UINT nErr);
Parameters: | nErr | The error code.
Return value: | A string description of the error code.
Notes: | This function converts an error value into a string describing the error.

Applications:

The following diagram describes in which case to use the configuration functions included in this library.

Note: The SMT6025 application can be replaced by anything which loads the SmtDrv.dll.


Without Diamond

If you are not using 3L Diamond on the DSP, you don't have all the functions provided in the case where you do have 3L Diamond. In this case, Sundance advise you to use the SMT6400 DSP software functions.

Config_FPGA_no3L.lib is the library to use when 3L Diamond is not used.

  • Functions

  • Applications

Functions:

 | ConfigStdioCP
Prototype: | UINT ConfigStdioCP (CCHAR *pcsFile, UINT nCp, UINT keyscheme, UINT nFpgaAddr);
Parameters: | pcsFile | Name of the bitstream file
 | nCp | Comport where the bitstream should be written out.
 | keyscheme | Startkey / endkey combination to use.
 | nFpgaAddr | Address of the FPGA.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the host system and send the file out via a comport. The function uses the stdio library to access the bitstream file and can be used when there is a 3L Diamond server or Code Composer Studio running on the host system.

 | ConfigFlashCP
Prototype: | UINT ConfigHscCP (UINT flash_address, UINT id, UINT nCp, UINT keyscheme, UINT nFpgaAddr);
Parameters: | flash_address | Address of the flash.
 | id | ID of the flash area where the bitstream is stored.
 | nCp | Comport where the bitstream should be written out.
 | keyscheme | Startkey / endkey combination to use.
 | nFpgaAddr | Address of the FPGA.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the flash memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | ConfigMemCP
Prototype: | UINT ConfigMemCP (UCHAR *pcBuf, UINT nBytes, UINT nCp, UINT keyscheme, UINT nFpgaAddr);
Parameters: | pcBuf | Address of the memory where the bitstream is stored.
 | nBytes | Size of the memory where the bitstream is stored
 | nCp | Comport where the bitstream should be written out.
 | keyscheme | Startkey / endkey combination to use.
 | nFpgaAddr | Address of the FPGA.
Return value: | Returns CFG_OK on success.
Notes: | This function reads a bitstream file from the DSP memory and send it out via a comport. The function can be used in any configuration, including a system without a host.

 | GetError
Prototype: | CCHAR * GetError(UINT nErr);
Parameters: | nErr | The error code.
Return value: | A string description of the error code.
Notes: | This function converts an error value into a string describing the error.

Applications:

The following diagram describes in which case to use the configuration functions included in this library.

The SMT6400 needs to be installed when using this configuration library as it gives a way to access the FPGA module.

Note: this software library ConfigFPGA_no3l.lib is SMT6400 libraries compliant (SmtTim.h and ModSup.h).

So a DSP application using this library is compiled and built with a makefile as it is described in the SMT6400 help file (i.e. the user is able to build a DSP application from any folder as the makefile uses global environment variables).


Configuring from FLASH

In this case the bitstream is stored on the module itself into a flash memory (or PROM).

Most FPGA type TIMs can select this mode by using switches on the TIM itself. Please refer to the user manual of your FPGA type TIM for more details.

The contents of the flash can only be changed with JTAG.

Note: not all FPGA modules have a flash on-board.


Firmware

Sundance uses a FPGA to implement the communication resources. Sundance has developed various communication resources such as comport, 16-bit SDB, 32-bit SDB, Global bus, RSL…

Sundance uses modularity in its designs to improve reusability and maintainability. This approach creates a number of elementary blocks which are used to create the firmware.


Model overview

The firmware of the modules supported by the SMT6500 is designed according to this model.

The FPGA is:

  • used to implement the communication interfaces,

  • connected to several peripherals. The role of the firmware is to allow these peripherals to exchange data,

  • connected to the peripherals via physical wires.

The peripherals may be zero or more processors, connectors or other components on the module.

The following diagram shows the FPGA connected to one processor, and two connectors.

The firmware comprises processor blocks, interface blocks, and connector blocks. All these blocks are interconnected with pre-defined signals. The connector and processor blocks are connected to the physical pins of the FPGA.

This is a standard case of figure. S ome modules do not have a processor connected to the FPGA. The firmware for these modules usually makes use of the standard connector blocks. The processor and the interface blocks may be replaced by a custom controller block.


Processor block

A processor block connects a processor to one or more interface blocks, allowing a processor to exchange data with interface blocks by accessing the resources inside the interface block.

The processor block translates the access made by the processor into a format that is understood by interface blocks.

The second main purpose of a processor block is to drive the event lines of the processor connected to it. Processor block uses triggers generated by interface blocks connected to it to generate events. Triggers are described in the section Appendixes.


Interface block

The interface block implements a collection of addressable resources (registers, and memory space mainly) that can be read or written by a processor block. Interface blocks usually drive connector blocks.

By accessing these resources, a processor block can:

  • obtain status information about the interface block and the connector block attached to it,

  • control the state of the interface block and the connector block,

  • transfer data to and from the connector block.

Each interface block can be connected to one processor block, one connector block, and zero or more interface blocks.

Processors might want to know when some condition is met inside the interface block. For example when the interface block has collected a certain number of words ready to be read. When such an event occurs, the interface block can generate a trigger. These triggers may be passed to other interface blocks and to processor blocks.

Some interface blocks, called event blocks, are dedicated to gather triggers and status information from other interface blocks, and to present them to a processor block. For example gathering the status and trigger information for all the SDB interfaces in the system. Typically, these interface blocks allow the user to select which trigger conditions should be passed to the processor block.

To indicate to a processor that a trigger condition has been met, the processor block uses event lines to the processor. The processor block may drive these event lines when the interface blocks connected to it present a trigger condition.


Connector block

The connector block forms the interface to the pins of the FPGA that are going to the connectors via physical wires.

It is usually responsible for transmitting and receiving data to and from physical wires.

The connector block has an interface that allows you to:

  • Send data

  • R eceive data

  • Control the connector block

  • O btain status

Connector blocks are usually designed to work in pairs, one side transmitting and the other side receiving. These are usually on different FPGAs, connected by physical wires. The connector block has control lines that are used to set the block to transmit or receive.

All connector blocks work in a similar way but may drive the physical wires differently. They work at different speeds, and have different signals and characteristics.

Sundance provides a number of standard connector blocks, such as comport, SDB and RSL.

Connector blocks are connected to interface blocks that drive them.


Implementation

This section describes the implementation of the model.

Each type of block (PB, IB, CB) has a standard interface. This interface is described in the files:

  • Smt_pkg.vhd,

  • IB_pkg.vhd,

  • CB_pkg.vhd,

  • and PB_pkg.vhd.


Processor block

Typically a processor connects to a peripheral using an address bus, a data bus, some control signals such as read, write and a few event lines.

In the case of a TIM with a DSP, the processor block decodes the address and the type of access made by processor. It also generates address and control signals (read, write) used to drive the interface block. In return the interface block will provide data and triggers to the processor block. Triggers will be used by the processor block to generate events on the event lines of the processor.

The processor block forms the gateway between the processor and the firmware.

The connection between a processor and a processor block is not defined. It depends on the details of the processor.

The connection between a processor block and an interface block are defined by two specific types described below.

The signals provided by processor block to interface block are grouped in the type t_PB_IB_X.

The type t_PB_IB_X gathers:

  • a data bus

  • an address bus

  • some control signals such as read and write

  • a clock signal

  • a reset signal

The signals provided by interface block to processor block are grouped in the type t_PB_IB_Y.

The type t_PB_IB_Y gathers:

  • a data bus

  • an address bus

  • some control signals such as read and write

  • a clock signal

  • a reset signal

  • a trigger bus

The processor block uses a SRAM type protocol to exchange data with the interface blocks.

When a processor writes data to an interface block, it presents the address, the data and the write signals on the bus for one clock cycle.

When a processor reads from the interface block, it presents the address and the read signal. The next cycle the interface block provides the data on the bus.


Interface block

The interface block is connected to a processor block. Each interface block has a region of the processor block’s memory space associated with it. When an access is made in this memory range, the interface block is responsible for dealing with the access. The allocation of the range of memory of an interface block can be done by specifying the properties of this interface block.

The properties allow to specify the start and the end address of the interface block. This is defined in the type t_IBProperties. This is the way the memory mapping of interface blocks is done.

Interface blocks can implement functionality that is accessed by means of resources inside the memory space associated with it. These resources can be used to control the interface block, to obtain status and to communicate data with other blocks further down in the design.

The pre-defined collection of addressable resources implemented by an interface block is called an “interface” from a software point of view. The software interfaces are described in the SMT6400 package.

Interface blocks can be used to drive a connector block.

Interface block and connector block are connected via a “data type” connecti on.

The interface block outputs an address bus, data bus, read and write signals.

It also provides a general purpose bus that can be used to transmit miscellaneous information between blocks. These signals are gathered in the type t_IB_CB.

These signals are used by the interface block to drive the connector blocks. The connector block provides the same signals back to the interface block.

The protocol used to exchange data between interface and connector block is the same than the one used between processor and interface block (SRAM type).

The way the interface block will drive the connector block depends on what functionality, if any, the interface block implements.

An interface block that does not implement any functionality, effectively passes the input address and data bus to the output.

An interface block can also connect to another interface block to exchange trigger information, gathered under the type t_Trigger. This type gathers the following information:

  • Trigger: when the condition of the trigger is met a pulse is generated on this line

  • Trigger_latch: this line becomes high when the condition is met. It stays high until it has been reset

  • Flag: the flag is usually the condition that generated the trigger. Only used for the comport

Some interface blocks (called event blocks) implement functionality dedicated to the processing of these triggers. They gather status and triggers of other blocks in the design


Memory mapping

The Processor block provides an address bus to interface blocks. The size of the address bus defines a memory space inside the FPGA addressable by the processor.

The Interface blocks decode the address bus to know if they are being accessed by the processor block. Because this address bus can be “big”, it may be expensive in terms of logic to decode all of the bits that constitute it. To simplify the address decoding, the total memory space defined by the address bus is divided into compartments of a certain size.

The top bits of the address are used to code the compartment number and the bottom bits used to access the resources inside a compartment. An interface block is affected a certain amount of compartments.

Interface block will react only when an access is made within the range of compartment affected to it. Effectively, only the top bits of the address bus are decoded by interface block to find out if it is being accessed. This way, the bigger the compartments are, the less bits are requested to decode the address (and the less logic is requested to decode the address). For historical reasons, the size of the compartments is fixed to 16K addresses (2^14) in the Sundance’s firmware.

The start and the end compartment of an interface block are specified by configuring its properties.

The type t_IBProperties allows to specify the following parameters:

  • SHIFT: the number of bits used to code the number of a compartment. The size of a compartment is 2^SHIFT

  • START: the number of the first compartment

  • END: the number of the last compartment

For example the comport interface request two compartments, and the SDB interface requests four compartments. The following diagram shows a possible memory arrangement for two comport interfaces and one SDB interface.

The first comport is located at compartments 0 and 1. The size of a compartment is 16K. Therefore the comport address range goes from 0x00000000 to 0x00004000, both included.

The same way, the second comport address range goes from 0x00008000 to 0x0000C000, both included.

The SDB is located at compartments 16 to 19. Its address range goes from 0x00040000 to 0x0004C000 both included.


Connector block

A connector block forms the link to the physical pins of the FPGA. A connector block is connected to an interface block.

Connection between connector block and the physical pins of the FPGA are not defined as they are specific to each connector block.

Connection between connector block and interface block is of type t_IB_CB.

Connector blocks may also exchange information with the top level of the FPGA, such as clock or reset. This connection is not defined as it is specific to each connector block. For the connector blocks that have it, this feature is usually gathered in types t_Global_CB_X and t_Global_CB_Y, provided in the package specific to the connector block.

Connector block may also be configured via a set of properties.

All connector blocks have some properties in common that are gathered in the type t_CBProperties. These properties allows to specify the identification number of the connector block.

These properties are not defined as they are custom to each connector block.


The types

The following table describes the signals constituting each of the types used to implement the firmware.

Signal | Length (bits) | Description
t_PB_IB_X signals going from the Processor Block to the Interface Block
CLK | 1 | Clock signal. The clock provided by the processor block to the interface blocks. The signals of the type t_PB_IB_X are synchronous to this clock.
RST | 1 | Reset signal used to reset the interface blocks.
ADDR | 32 | Address bus.
DATA | 32 | Data bus.
READ | 1 | Read command signal.
WRITE | 1 | Write command signal.
t_PB_IB_Y signals going from the interface block to the processor block
CLK | 1 | Clock signal. The clock provided by the interface blocks to the processor block. The signals of the type t_PB_IB_Y are synchronous to this clock. Usually this is the same clock than the clock provided by the processor block to the interface blocks.
RST | 1 | Reset signal used by the interface block to reset the processor block.
ADDR | 32 | Address bus.
DATA | 32 | Data bus.
READ | 1 | Read enable signal. The interface block drives this signal to read data from the processor block.
WRITE | 1 | Write enable signal. The interface block drives this signal to write data to the processor block.
TRIGGERS | 32 | Triggers comings from the interface blocks. The interface blocks can output triggers directly to the processor via this bus. There are 32 triggers at the most. Usually only the event blocks drive this bus. The other interface blocks tri-state it.
t_IBProperties properties common to all interface blocks Interface blocks may also have custom properties
SHIFTRIGHT | Integer | The size of a compartment in number of bits. The size in bytes is : (2^ShiftRight)*sizeof(int).
SHIFTLEFT | Integer | The top bits of the address bus provided by the processor block to be ignored when decoding the address.
STARTC | Integer | The number of the first compartment
ENDC | Integer | The number of the last compartment
t_IB_CB signals flowing between the interface block and the connector block This type is used for signals going in both directions
CLK | 1 | Clock signal. All the other signals of the type t_IB_CB are synchronous to this clock
RST | 1 | Reset signal used to reset the interface block or the connector block.
ADDRESS | 32 | Address bus.
READ | 1 | Read enable signal.
WRITE | 1 | Write enable signal.
DATA | 32 | Data bus.
GENERAL | 128 | General purpose bus. Refer to the implementation document for the description of this bus.
ENABLE | 1 | Do not use
t_Trigger the trigger signals going from the interface blocks to the event blocks
TRIGGER | 1 | The event indicating when the condition is met (pulse)
TRIGGER_LATCH | 1 | Keeps memory of the event until it has been reset
FLAG | 1 | Usually the condition that generated the trigger
t_Global_CB_X signals going from the top level to the connector blocks
CLK | 1 | External clock signal
RST | 1 | External reset signal
t_Global_CB_Y
CLK | 1 | Clock provided by connector block to global logic
RST | 1 | Reset provided by connector block to global logic


Sundance firmware

This section provides the description of the main blocks constituting Sundance firmware:

  • Comport,

  • Sundance Digital Bus,

  • Rocket-IO Serial Link,

  • Global Bus,

  • Processor block,

  • Miscellaneous.


The FIFO link

Most of the Sundance’s blocks use the following mechanism to transfer data.

A FIFO may be needed in connector block to store data that can not be transmitted immediately (for example when the connector block is not set as transmitter). In the same way, the interface block also has a FIFO to keep data that arrives from the connector block. This FIFO arrangement also means that burst accesses can be made.

To avoid the interface block sending data to the connector block when its FIFO is full, the connector block reports its FIFO status to the connector block. Likewise, the interface block reports its FIFO status to the connector block. Data is only sent to a FIFO if the FIFO has space for data.

This symmetrical arrangement is shown hereunder. The figure shows that an IB and a CB are connected with two opposing FIFO links.

This mechanism is used by some of Sundance’s interface and connector blocks to exchange data. In this case, connector block contains a FIFO and some glue logic that is connected to a Physical Layer Block (PLB) that provides the very low level access to the pins of the FPGA.

The PLB has control lines that are used to set it up to transmit or to receive data to and from physical wires.

The glue logic is in charge of driving PLB to transfer data. When transmitting the glue logic checks that the PLB is ready to transmit before providing data to it. The same way, glue logic has to indicate to the PLB to stop providing data when it can’t receive anymore data (when the FIFO is full for example).

In addition, the interface block provides extra control signals to connector block. These signals can be used to reset the connector block’s FIFO or the PLB for example. The same way, connector block provides extra status information to interface block, such as the state of its PLB.

Comport and SDB connector and interface blocks implement this mechanism.


Comport

The Comport interface is composed of the three elementary blocks:

  • Connector Block,

  • Interface Block,

  • Event Block.


Connector block

Comport connector block connects to comport interface block via two FIFO links going each in opposite directions.

Comport interface block is described in the next section.

The following table gives the description of the signals of the comport connector block.

Signal name | Direction | Description
t_CBProperties properties
P.Id |  | Identity number of the connector block.
t_IB_CB signals coming from interface block
I_ib.clk | In | All signals constituting bus i_ib are synchronous to this clock
I_ib.rst | In | General reset for connector block
I_ib.data | In | Data bus. Data present on this bus will be written in connector block FIFO and sent to physical wires
I_ib.write | In | High when data is valid
I_ib.General(34) | In | Reset connector block input logic (FIFO)
I_ib.General(35) | In | Reset PLB
I_ib.General(36) | In | PLB control signal. Sets priority between transfer and bus exchange. When '1' priorities are equal, when '0' transmitter has priority
I_ib.General(37) | In | PLB control signal. When this bit set is reset, PLB Set the flow control (i.e. interruption of the transmission when input FIFO is full). '1' flow controlled, '0' none
I_ib.General(38) | In | Set the initial state of the PLB (receiver or transmitter)
t_IB_CB signals going to interface block
O_ib.clk | Out | All signals constituting bus o_ib are synchronous to this clock
O_ib.rst | Out | Must be 0
O_ib.data | Out | Data bus. Data present on this bus will be written in connector block FIFO
O_ib.write | Out | High when data is valid
O_ib.General(31..0) | Out | Connector block FIFO level
O_ib.General(32) | Out | Connector block FIFO full flag
O_ib.General(33) | Out | Connector block FIFO empty flag
General(34) | Out | PLB status signal. When high, indicates that PLB is transmitting
General(35) | Out | PLB status signal. When high, indicates that PLB is ready to transmit
General(36) | Out | PLB status signal. When high, indicates that PLB is ready to receive
t_Comport_Pins physical wires going to connector
Io_pins | Inout | t_Comport_Pins. The comport bus.


Interface block

The complete description of the comport interface is available in the SMT6400 help file.

The following diagram shows the functional description of the comport interface block.

Usually, a processor block and a comport connector block are connected to the comport interface block.

Comport interface block contains 2 addressable resources. A control and status register (CP_CSR) and a data register (CP_DAT). Processor block can read and write both resources.

Writing to the comport data register (CP_DAT) will cause the data to be written inside the FIFO of the comport connector block. Also, data received by the comport connector block is accessed by reading the CP_DAT register.

Processor block can read status of both comport connector block and interface block stored in CP_CSR (such as FIFO levels, state of the PLB) and write commands into it.

Comport interface block can also generate triggers depending on the level of the FIFOs. CP_CSR contains information to enable or disable triggers.

The following table gives the description of the signals of the comport interface block.

Signal name | Direction | Description

t_IBCpProperties

properties

P.P_Ib.Shift

Size of a compartment

P.P_Ib.StartC

Start compartment. EndC/StartC must be greater to 2 for a comport interface block
P.P_Ib.EndC | End compartment
P.P_Ib.size | Size of the FIFO (2^size)
P.P_Ib.Impl

Implementation type:

  • c_IMPL_TRX

  • c_IMPL_RCX

  • c_IMPL_ALL

t_IB_CB

signals going to connector block

O_cb.clk | Out | All signals constituting bus o_cb are synchronous to this clock
O_cb.rst | Out | General reset for connector block
O_cb.data | Out | Data bus. Data present on this bus will be written in connector block FIFO
O_cb.write | Out | High when data is valid
O_cb.General(34) | Out | Reset connector block input logic (FIFO)
O_cb.General(35) | Out | Reset PLB
O_cb.General(36) | Out | PLB control signal. Sets priority between transfer and bus exchange. When '1' priorities are equal, when '0' transmitter has priority
O_cb.General(37) | Out | PLB control signal. When this bit set is reset, PLB Set the flow control (i.e. interruption of the transmission when input FIFO is full). '1' flow controlled, '0' none
O_cb.General(38) | Out | Set the initial state of the PLB (receiver or transmitter)

t_IB_CB

signals coming from connector block

I_cb.clk | In | All signals constituting bus i_cb are synchronous to this clock
I_cb.rst | In | Must be 0
I_cb.data | In | Data bus. Data present on this bus will be written in connector block FIFO
I_cb.write | In | High when data is valid
I_cb.General (31..0) | In | Connector block FIFO level
I_cb.General (32) | In | Connector block FIFO full flag
I_cb.General (33) | In | Connector block FIFO empty flag
I_cb.General (34) | In | PLB status signal. When high, indicates that PLB is transmitting
I_cb.General (35) | In | PLB status signal. When high, indicates that PLB is ready to transmit
I_cb.General (36) | In | PLB status signal. When high, indicates that PLB is ready to receive

t_TriggerControl

s ignals coming from event block

I_trig_ctl(1..0) In Triggers generation control.

When i_trig_ctl(i) is high, trigger generation is enabled. When i_trig_ctl(i) is low, trigger generation is disabled and o_trigger(i) stays low

t_TriggerVector

signals going to event block

O_trigger(0).trigger | Out | Input condition asserted event (pulse)
O_trigger(0).flag | Out | Input FIFO not empty
O_trigger(0).trigger_latch | Out | Latched version of O_trigger(0).trigger
O_trigger(1).trigger | Out | Output condition asserted event (pulse)
O_trigger(1).flag | Out | Output FIFO not empty
O_trigger(1).trigger_latch | Out | Latched version of O_trigger(1).trigger

t_PB_IB_X

signals coming from processor block

I_pb.clk | In | Processor block clock. All signals constituting bus i_pb are synchronous to this clock
I_pb.rst | In | General reset for interface block
I_pb.addr | In | Address bus
I_pb.data | In | Data bus
I_pb.read | In | Read request
I_pb.write | In | Write request

t_PB_IB_Y

signals going to processor block

O_pb.clk | Out | Tri-stated
O_pb.rst | Out | Tri-stated
O_pb.addr | Out | Tri-stated
O_pb.data | Out | Data bus
O_pb.read | Out | Tri-stated
O_pb.write | Out | Tri-stated


Event block

The comport event block manages the triggers generated by the comport interface blocks and passes the result to the processor block. The processor block will use these to drive the event lines of the processor.

When connected to connector block CB_ExtInt, it also manages triggers coming from IIOF lines.

Event block comport and global bus works in a similar way that event block SDB.


Sundance Digital Bus

The Sundance Digital Bus interface is composed of the three elementary blocks:

  • Connector Block,

  • Interface Block,

  • Event Block.


Connector block

SDB connector block connects to SDB interface block via two FIFO links going each in opposite directions.

By configuring the mode, it is possible to select if the SDB connector block will behave as a 16-bits SDB, or as a 32-bits SDB.

It is also possible to implement limited versions of the SDB connector block to limit the resource usage in the FPGA. For example you can implement a transmitter only SDB. In this case the logic that usually handles the reception of the data is trimmed out from the design.

The following table gives the description of the signals of the SDB connector block.

Signal name | Direction | Description

t_CBSdbProperties

Properties

P.mode

t_CBSdbProperties

SDB connector block mode:

  • c_sdb_16bits_mode

  • c_sdb_32bits_mode
P.Id

t_CBSdbProperties

Identity number of the connector block
P.Impl t_CBSdbProperties Implementation type:
  • c_IMPL_TRX: implements a transmitter only SDB
  • c_IMPL_RCX: implements a receiver only SDB
  • c_IMPL_ALL: implements a bi-directional SDB

signal coming from global logic

I_global.clk | In | Clock for SDB PLB. Data are sent on SDB bus synchronously to this clock

t_IB_CB

signals coming from interface block

I_ib.clk | In | All signals constituting bus i_ib are synchronous to this clock
I_ib.rst | In | General reset for connector block
I_ib.data | In | Data bus. Data present on this bus will be written in the FIFO of the connector block
I_ib.write | In | High when data is valid
I_ib.General(34) | In | Reset connector block input logic (FIFO,…)
I_ib.General(35) | In | Reset PLB
I_ib.General(36) | In | PLB control signal. Sets priority between transfer and bus exchange. When '1' priorities are equal, when '0' transmitter has priority
I_ib.General(37) | In | PLB control signal. When this bit set is reset, PLB Set the flow control (i.e. interruption of the transmission when input FIFO is full). '1' flow controlled, '0' none
I_ib.General(38) | In | Set the initial state of the PLB (receiver or transmitter)

t_IB_CB

s ignals going to interface block

O_ib.clk | Out | All signals constituting bus o_ib are synchronous to this clock
O_ib.rst | Out | Connected to ground
O_ib.data | Out | Data bus. The data received by PLB from physical wires
O_ib.write | Out | High when data is valid
O_ib.General(31..0) | Out | Connector block FIFO level
O_ib.General(32) | Out | Connector block FIFO full flag
O_ib.General(33) | Out | Connector block FIFO empty flag
O_ib.General(34) | Out | PLB status signal. When high, indicates that PLB is transmitting
O_ib.General(35) | Out | PLB status signal. When high, indicates that PLB is ready to transmit
O_ib.General(36) | Out | PLB status signal. When high, indicates that PLB is ready to receive

t_Sdb_Pins

physical wires going to connector

Io_pins_d Inout 16-bits SDB data bus. Type t_Sdb_Pins.

When 16-bits mode, this is the data bus.

In 32-bits mode the less significant 16 bits are carried on this bus

Io_pins_e Inout 32-bits SDB data bus. Type t_Sdb_Pins.

Irrelevant when 16-bits mode selected.

In 32-bits mode the most significant 16 bits are carried on this bus.


Interface block

The complete description of the SDB interface is available in the SMT6400 help file.

The following diagram shows the functional description of the SDB interface block.

Usually, a processor block and a SDB connector block are connected to the SDB interface block.

SDB interface block contains 4 addressable resources. A control and status register (SDB_CSR), a data register (SDB _DAT) and two registers to configure the trigger generation (SDB_OTRIG, SDB_ITRIG). Processor block can read and write both resources.

Writing to the SDB Data Register (SDB _DAT) will cause the data to be written inside the SDB connector block’s FIFO. Also, data received by the SDB connector block is read by reading the SDB _DAT register.

Processor block can read status of both SDB connector block and interface block stored in SDB _CSR (such as FIFO levels, state of the PLB) and write commands into it.

SDB interface block can also generate triggers depending on the level of the FIFOs. SDB_OTRIG and SDB_ITRIG registers contain information to enable or disable triggers.

The following table gives the description of the signals of the SDB interface block.

Signal name | Direction | Description

t_IBSdbProperties

properties

P.P_Ib.Shift

Size of a compartment

P.P_Ib.StartC

Start compartment
P.P_Ib.EndC | End compartment. Note that EndC – StartC must be greater to 4 for a SDB interface block
P.P_Ib.size | Size of the FIFO (2^size)
P.P_Ib.Impl Implementation type:
  • c_IMPL_TRX
  • c_IMPL_RCX
  • c_IMPL_ALL

signals going to connector block

O_cb.clk | Out | All signals constituting bus o_cb are synchronous to this clock
O_cb.rst | Out | General reset for connector block
O_cb.data | Out | Data bus. Data present on this bus will be written in connector block FIFO
O_cb.write | Out | High when data is valid
O_cb.General (34) | Out | Reset connector block input logic (FIFO,…)
O_cb.General (35) | Out | Reset PLB
O_cb.General (36) | Out | PLB control signal. Sets priority between transfer and bus exchange. When '1' priorities are equal, when '0' transmitter has priority
O_cb.General (37) | Out | PLB control signal. When this bit set is reset, PLB Set the flow control (i.e. interruption of the transmission when input FIFO is full). '1' flow controlled, '0' none
O_cb.General (38) | Out | Set the initial state of the PLB (receiver or transmitter)

signals coming from connector block

I_cb.clk | In | All signals constituting bus i_cb are synchronous to this clock
I_cb.rst | In | Must be 0
I_cb.data | In | Data bus. Data present on this bus will be written in connector block FIFO
I_cb.write | In | High when data is valid
I_cb.General (31..0) | In | Connector block FIFO level
I_cb.General (32) | In | Connector block FIFO full flag
I_cb.General (33) | In | Connector block FIFO empty flag
I_cb.General (34) | In | PLB status signal. When high, indicates that PLB is transmitting
I_cb.General (35) | In | PLB status signal. When high, indicates that PLB is ready to transmit
I_cb.General (36) | In | PLB status signal. When high, indicates that PLB is ready to receive

signals coming from event block

i_trig_ctl(1..0) In Triggers generation control.

When i_trig_ctl(i) is high, trigger generation is enabled. When i_trig_ctl(i) is low, trigger generation is disabled and o_trigger(i) stays low

signals going to event block

O_trigger(0).trigger | Out | Input condition asserted event (pulse)
O_trigger(0).flag | Out | Input FIFO not empty
O_trigger(0).trigger_latch | Out | Latched version of O_trigger(0).trigger
O_trigger(1).trigger | Out | Output condition asserted event (pulse)
O_trigger(1).flag | Out | Output FIFO not empty
O_trigger(1).trigger_latch | Out | Latched version of O_trigger(1).trigger

signals coming from processor block

I_pb.clk | In | Processor block clock. All signals constituting bus i_pb are synchronous to this clock
I_pb.rst | In | General reset for interface block
I_pb.addr | In | Address bus
I_pb.data | In | Data bus
I_pb.read | In | Read request
I_pb.write | In | Write request

signals going to processor block

O_pb.clk | Out | Tri-stated
O_pb.rst | Out | Tri-stated
O_pb.addr | Out | Tri-stated
O_pb.data | Out | Data bus
O_pb.read | Out | Tri-stated
O_pb.write | Out | Tri-stated


Event block

The SDB event block manages/filters the triggers generated by the SDB interface blocks and passes the result to processor block. Processor block will use the information provided by the event block to drive the event lines of the processor.

The SDB event block gathers the four event control registers (SDB_ECR) associated with each of the C6000 external event lines (EXT_INTx) and the SDB global status register (SDB_GSR) gathering all the events for all SDB resources.

The complete description of the SDB event block functionality is available in the SMT6400 help file.

SDB event block can be connected to one processor block and 16 SDB interface blocks at the most.

By writing in one of the four ECRs you can select which one of the triggers generated by the SDB interface blocks will be associated with the corresponding EXT_INT line.

The content of each one of the four ECRs is masked with the triggers coming from the interface blocks on the bus I_trigger(31..0). If the result is different of zero then a pulse is generated on the corresponding trigger line going to processor block.

The processor block will use these triggers to drive the processor’s event lines. Event block SDB connects to the processor block via lines o_pb.triggers(7..4). The other lines are not driven by the block.

Note that writing into the ECRs re-initialises the logic responsible for the trigger generation in the interface block.

Event block SDB also acts as a central point by gathering status of the triggers into SDB_GSR.

When an event happens, processor can read SDB_GSR and quickly find out which one of the SDB interfaces has interrupted.

The following table gives the description of the signals of the SDB event block.

Signal name | Direction | Description
signals going to interface blocks
O_trig_ctl(31..0) | Out | Trigger control bus. When high it allows the corresponding trigger to be generated by interface bock. O_trig_ctl(i) is high when ECR4(i)=1 or ECR5(i) =1 or ECR6(i) =1 or ECR7(i) =1
signals coming from interface blocks
I_trigger(31..0) | In | Triggers coming from interface blocks
signals coming from processor block
I_pb.clk | In | Processor block clock. All signals constituting bus i_pb are synchronous to this clock
I_pb.rst | In | General reset for interface block
I_pb.addr | In | Address bus
I_pb.data | In | Data bus
I_pb.read | In | Read request
I_pb.write | In | Write request
signals going to processor block
O_pb.clk | Out | Tri-stated
O_pb.rst | Out | Tri-stated
O_pb.addr | Out | Tri-stated
O_pb.data | Out | Data bus
O_pb.read | Out | Tri-stated
O_pb.write | Out | Tri-stated
O_pb.triggers(31..0) | Out | Trigger bus going to processor block O_pb.triggers(31..8) is tri-stated. O_pb.triggers(7..4) gathers events going to EXT_INT4, EXT_INT5, EXT_INT6 and EXT_INT7. O_pb.triggers(3..0) is tri-stated.


Global Bus

The global bus is an exception to the model of the firmware.

The block IB_GlobalBus gathers the interface block and the connector block. It is connected on one hand to the processor block and on the other hand to the pins going to the global bus connector.

The global bus is partially designed in schematics instead of VHDL files.


Event block

The global bus and the comports share the same event block: EB_ComportGb.

The EB_ComportGb is also connected to the connector block CB_ExtInt that manages the triggers coming from IIOF lines.


Processor block

This section provides the description of the DSP processor block part of the DSP type TIM firmware.


DSP block

Sundance DSP TIMs interface a Texas Instrument DSP with the FPGA.

The DSP can interface to various types of peripherals such as SDRAM, SRAM...

The FPGA is connected to the DSP via the External Memory Interface (EMIF). The EMIF allows the DSP to access various types of peripherals such as SDRAM.

The FPGA and the DSP are interface using the SDRAM protocol. The DSP is configured to access an SDRAM and the DSP processor block implemented in the FPGA acts as an SDRAM.

The DSP processor block decodes the SDRAM accesses made by DSP and generates an address bus, a data bus and read/write signals to access interface blocks.

The DSP processor block also the DSP’s event lines: EXT_INT4, EXT_INT5, EXT_INT6, EXT_INT7. It gathers the triggers generated by the interface blocks connected to it and uses them to drive the event lines.


Miscellaneous

This section provides the description for some miscellaneous block that are useful to build a firmware.

The following firmware blocks are discussed:

  • General purpose interface,

  • LED,

  • NMI and Config lines,

  • Connector block TCLK,

  • Processor interconnection.


General purpose interface block

This interface block is used to implement access to the LED, NMI/Config and Tclk lines.


LED

The connector block LED (CB_Led) is used to drive the LED connected to the FPGA.

It is usually connected to the interface block IB_Gp_Range.


NMI/CONFIG

The connector block CB_NmiConfig is used to drive the NMI and CONFIG lines.

This connector block allows to route the NMI signal coming from the TIM connector to the processor NMI pin.

It also allows to drive the CONFIG line described in the TIM specification.

The TIM specification describes the operation of an open-collector type signal CONFIG that is driven low after reset.

This signal, on a standard C4x based TIM, is connected to the processor’s IIOF3 pin.

On Sundance’s modules the CONFIG signal is asserted after power on, and can be released by writing the value (1<<6) to the config register. Conversely, CONFIG may be reasserted by writing 0 to this bit. It is not possible for software to read the state of the CONFIG signal.


Connector block TCLK

The connector block CB_Tclk is used to drive the TIM TCLKx pins.

It is connected to an interface block IB_Gp_Range that provides access to the register used to control the pins. The description of the register is given below.

This table describes the TCLK0 and TCLK1 bits:

Field | Description
TCLKx | 0 | TIM TCLKx is set as an input
 | 1 | TIM TCLKx is set as an output

If the TIM TCLKx pin is selected as an output, the DSP TOUTx signal will be used to drive it. The TIM TCLKx pin will always drive the DSP TINPx input.


Processor interconnection

This connector block allows two processor connected to the FPGA to communicate with each other using the standard Sundance’s interfaces.

It interconnects two SDB or comport interface blocks together without adding any logic.

It is used to implement the firmware for multi-processor modules.


Design environment

This section describes how to simulate the Sundance firmware, and how to compile it to generate a bitstream.

The firmware is compiled to generate a bitstream that is used to configure the FPGA.

The compilation of the VHDL occurs in two stages. The firmware is first synthesised to produce a netlist. It is then placed and routed in the targeted FPGA to produce the bitstream.


Firmware layout

The firmware for the Sundance FPGA-based modules uses the Sundance blocks library.

The sources of the library are provided in the folder ..\Program Files\Sundance\SMT6500\FPGA\src\Shared

The source code for each of the Sundance modules is provided in the folder src\SMTxxxx, where xxxx is the number of the board (for example SMT395Q, xxxx=395Q).

The directory structure installed is shown below.

There are three main directories: Src and compile that gather the source code, and synthesis that contains the projects to build the bitstreams for the modules.

  • Src\shared\general: this directory provides sources for components that are used in many blocks. Typically this is where the file Smt_pkg.vhd is located.

  • Src\shared\CB: this directory provides the sources for the connector blocks.

  • Src\shared\CB\PLB: this directory provides sources for the physical layer blocks.

  • Src\shared\IB: this directory provides the sources for the interface blocks.

  • Src\shared\PB: this directory provides sources for the processor blocks.

  • Src\smtxxx: this directory provides sources for SMTxxx module (top level, VHDL components specific to the module and user constraint file).

  • Synthesis\SMTxxx: this directory provides the Xilinx ISE project to build the modules and the default bitstream provided by Sundance.

The following table provides the list of the files used to describe the various blocks constituting the firmware. These files should be passed to the synthesize tool when compiling firmware.

Note: For all blocks files available in folder Src\shared\General should be included into the project.

Blocks | Sources
Connector blocks | Src\shared\CB\CB_pkg.vhd
Comport connector block | Src\shared\CB\comport\*.* Src\shared\CB\comport\PLB\*.*
SDB connector block | Src\shared\CB\SDB\*.* Src\shared\CB\SDB\PLB\*.*
Led connector block | Src\shared\CB\LED\*.*
Tclk connector block | Src\shared\CB\Tclk\*.*
NmiConfig connector block | Src\shared\CB\ NmiConfig \*.*
ExtInt connector block | Src\shared\CB\ ExtInt \*.*
Interconnect connector block | Src\shared\CB\ Interconnect \*.*
IntLink connector block | Src\shared\CB\ IntLink \*.*
Interface blocks | Src\shared\IB\IB_pkg.vhd
Comport interface block | Src\shared\IB\IB_comport\*.*
SDB interface block | Src\shared\IB\IB_SDB\*.*
Global bus | Src\shared\IB\IB_GlobalBus\*.*
Gp_Range interface block | Src\shared\IB\IB_Gp_Range \*.*
Event block SDB | Src\shared\IB\EventManager_pkg.vhd Src\shared\IB\EventManager.vhd Src\shared\IB\EB_Sdb\*.*
Event block comport global bus | Src\shared\IB\EventManager_pkg.vhd Src\shared\IB\EventManager.vhd Src\shared\IB\EB_ComportGb\*.*
Processor blocks | Src\shared\PB\PB_pkg.vhd
DSP processor block | Src\shared\PB\Dsp\*.*
DSP Gateway | Src\shared\PB\DSP_Gateway\*.*
DSP A SRAM | Src\shared\PB\DspASram\*.*


Simulation

This sections describes how you can simulate the FPGA firmware.

To be able to simulate a FPGA design, the Design Engineer requires:

  • Tools,

  • and Testbench.


Tools

In this section you will find how to simulate the VHDL sources constituting the firmware. The firmware must be compiled by the simulator in a library called Smt.

The procedure may depend on the VHDL environment used. We only give guidelines for the simulator ALDEC Active-HDL.

First, you should integrate all the VHDL source files available in the directory “Shared” into your project as a library called Smt.

This is very important, because the default working library for a VHDL project is work. You perhaps need to create the library Smt. To do so, open the library manager, right click in the library list and choose “create new” from the menu. Type “Smt” as name for the library and choose create an empty library. Click “OK”. The library “Smt” should appear in the list of libraries.

Execute compile.do macro to compile the VHDL source files into the library.


Testbench

Sundance provides a testbench with each of the modules to simulate the FPGA.

Executing the functional.do macro available in the directory of the module will start the simulation of the design. Results will be displayed in a waveform file.

A basic VHDL model of the DSP is provided for the modules embedding a DSP on-board. This model provides a set of functions simulating the accesses the DSP makes to the FPGA (for example read and write registers).

The description of the model will be provided in a more complete version of this document.


Compilation

In this section you will find how to build (synthesize, implement, place and route) the VHDL sources constituting the firmware to create the bitstream. The firmware is synthesized in a library called Smt. The content of this library is then used to build the firmware for a board.

This procedure strongly depends on the VHDL environment you are using. We can only give the detailed procedure for Xilinx ISE and XST, but we hope the general guidelines will be precise enough for other environments.

Remark: if you feel like contributing to this section, we welcome the procedures for the missing VHDL environments, we will be glad to integrate them in this document.


Xilinx ISE

First, you should integrate all the VHDL source files available in the directory “Shared” into your project as a library called Smt.

This is very important, because the default working library for a VHDL project is work. You perhaps need to create the library Smt before and then add the whole source tree (including all sub-directories) to this library.

This section guides you through the different steps required to integrate Smt library to your project using Xilinx ISE tools and their graphical front-end (Project Navigator). The result is saved in the .ise file (or .npl for the older Xilinx ISE versions).

Before starting, you should have opened or created your project in the Xilinx Project Navigator (File -> Open project/New project).

You should focus on the Sources in project window (you can show and hide it from the View menu: View -> Sources), and more precisely on the Library View tab.

Then, right-click in this tab, and select New Source. In the dialog box that opens, select VHDL Library for the source type, and type “Smt” for the file name. Make sure that the Add to project box is ticked, and click on Next and then Finish. Now the Smt library is created.

Third, you need to add all the VHDL sources in the folder “..\src\Shared” to the library Smt in the Library View. Right-click on the Smt library, select Add Source, and select all the Sundance’s library source files.

Note: this operation does not recursively add all sub-folders, so you will have to do this manually! Eventually, when all the source are added, the Smt library will be ready to be used.


Xilinx XST

The following section gives the options that should be used to synthesize the firmware with Xilinx XST.

For some module a synthesis XST constraint file (.xcf) may be used.


Xilinx implementation

The implementation is made using Xilinx ISE tools.

The following options should be chosen for this step:

Note: the other options not shown in the previous screenshots can remain configured by Default.


Xilinx programming file generation

The following section gives the options that should be used to generate the bitstream of the firmware with Xilinx ISE.

Note: the other options not shown in the previous screenshots can remain configured by Default.


Example

This section describes an example to create the Sundance firmware for the SMT365 DSP module through.


SMT365

This section describes the example of the SMT365. It shows how the features of the FPGA can be described in a top-level VHDL file, and how the firmware is built to make the bitstream.

The SMT365 is a single width module that connects a Texas Instrument C6416 DSP to a Xilinx Virtex-II FPGA. Refer to the SMT365 user guide for more details about the module.

This example implements six comports, two 32-bits SDBs, and one global bus in the FPGA. It also implements 4 LEDs, NMI, CONFIG line and TCLK functionalities.

The source files specific to SMT365 are available in the folder ..\SMT6500\FPGA\src\SMT365\SMT365_32_2.

The project for the compilation is in the folder ..\SMT6500\FPGA\synthesis\SMT365_32_2.

The description of the firmware is made in the top-level file SMT365_32.vhd.

The list of blocks to implement is as follow:

  • 1x DSP processor block

  • 6x Comport interface blocks

  • 2x SDB interface blocks

  • 1x Global bus interface block

  • 1x Comport and global bus event block

  • 1x SDB event block

  • 3x General purpose interface block to control LEDs, NMI and TCLK functionalities

  • 6x Comport connector blocks

  • 2x 32-bits SDB connector blocks

  • 1x LED connector block

  • 1x NMI connector block

  • 1x TCLK connector block

This top-level file is split between the 6 sections listed hereunder:

Section | Description
0 | List of packages
1 | Entity declaration
2 | Signal declaration
3 | Properties initialisation
4 | Components instantiation
5 | Components interconnection


List of package

Each block provided in the firmware comes with a package in which the block’s component and the types associated with it are declared. The packages are also used to declare subprograms, or types that are shared by many blocks. For example, the comport interface block is declared in the package IB_comport_pkg.vhd.

In this section, we declare the packages for the blocks that we wish to use.

The following picture shows the VHDL code for SMT365.


Entity declaration

This is the description of the entity of the FPGA.

Pre-defined types are provided for Sundance communication links. They are defined in the connector blocks’ packages and in the processor blocks’ packages.

For example there is a type t_Comport_Pins grouping the definition of the pins for the comport. This type is defined in CB_Comport_pkg.vhd.


Signals declaration

This section declares the signals that will be used to connect blocks together. There is always one set of signals per block.

The communication resources are numbered as a convention:

  • ComPort Interface Blocks: IB0 to IB5

  • ComPort Event Blocks: EBA

  • SDB Interface Blocks: IB10 to IB15

  • SDB Event Blocks: EBB

  • Global Bus Interface Block: IB99

  • LED Interface Block: IB90

  • CONFIG Interface Block: IB91

  • TCLK Interface Block: IB92


Properties initialisation

This is in this section that the properties of the blocks are defined.

Defining the properties of the blocks allows to define the memory space of the FPGA as well as the features of the various blocks. Most application do not request to change the value of these properties.


Blocks instantiation

The various blocks composing the design are instantiated in this section.

This instantiation has to be done for all the blocks implemented in the firmware:

  • DSP_Gateway Blocks,

  • Processor Blocks,

  • Interface Blocks,

  • Event Blocks,

  • Connector Blocks.


Blocks interconnection

This is the last step of the design. This is in this section that the blocks constituting the design are interconnected together.


Simulation

A testbench (TB.vhd) is provided to simulate this design in the folder ..\SMT6500\FPGA\src\SMT365\SMT365_32\Simulation. For the users of Aldec Active-HDL, the file functionnal.do and timing.do runs the simulation, and the result is displayed in the file waveform.awf.

Note that the Smt library should have been compiled first using the compile.do macro provided with the library.


Implementation

The ISE project is provided for the SMT365 is provided in the folder ..\SMT6500\FPGA\synthesis\SMT365_32_2.

In the window named Sources in project select SMT365_32-struct. Then build the firmware by double clicking on generate programming file in the Process View window.

At the end of the compilation, the tool generates a bitstream that can be downloaded into the FPGA of the SMT365 using the SMT6001 utility tool.


Appendixes

  • Trigger Generation

  • Sundance resource details


Trigger generation

An interface block can generate triggers.

A trigger is defined as:

  • a pulse that shows when the event happens

  • a latched value that records that the events has happened

A trigger is generated when a status reaches a certain set-point.

Once a trigger has happened it is necessary to reset it to be able to generate a new one.

For example a trigger can be used to monitor the state of a FIFO. In this case, the actual value represent the level of the FIFO and the set-point represents the value of a register that user sets up. When FIFO level matches with the specified set-point then a trigger is generated.

Trigger is cleared as soon as user reads or writes FIFO.


Resources details

This section gives the details about the communications resources:

  • Comport

  • Sundance Digital Bus

  • Rocket-IO Serial Link

  • Global bus


Comport

The comport interface is described in the Sundance help file.

A comport is an 8-bits asynchronous link that sustains up to 20 MB/s data rate. The comport protocol is specified by Texas Instruments.

From a hardware point of view, the comport interface is a simple one-to-one asynchronous bidirectional interface via 8 data lines and 4 control lines.

  • Request: creq is the comport token request. The DSP activates this signal to request the use of the comport data bus.

  • Acknowledge: cack is the comport token acknowledge. The DSP activates this signal to relinquish ownership of the comport data bus upon receiving a nreq signal from another DSP.

  • Strobe: cstrb is the comport strobe signal. A sending DSP activates this signal to indicate it has placed a valid data byte on the comport data bus.

  • Ready: crdy is the comport ready signal. A receiving DSP activates this signal to indicate it has received a data byte via the comport data bus.

  • Data: cd(7:0) is the comport data bus. This bus carries data bidirectionally, one byte a time, between DSP and other device.

More details can be found in the comport technical specification document.


Physical layer

The following table describes the comport connector interface

Signal name | Bus width (bit) | Description
CD | 8 | Comport data bus
CREQ | 1 | Comport request. The interface activates this signal to request the use of the bus
CACK | 1 | Comport acknowledge. The interface activates this signal to indicate it releases the comport bus upon receiving a CREQ
CSTRB | 1 | Date strobe. The interface activates this signal to indicate it has place a valid byte on the data bus
CRDY | 1 | Comport ready. The receiving comport activates this signal to indicate it has received a data byte

The chronogram below shows a transfer of data: the comport transfer words is based on a byte-to-byte exchange, where the LSB is send first. The transfer operation requires handshaking of signals CSTROB and CRDY.

Description:

0 - B owns the token and has data to transmit.

1 - B drives the first byte onto CDb(7–0) on H1 falling (plus analog delay).

2 - B brings CSTRBb low on H1 rising (plus analog delay).

3 - After a transmission line time delay, A sees CSTRBa go low, signaling valid data.

4 - A reads the data and then brings CRDYa low

5 - After a transmission line time delay B sees CRDYb go low, signaling data has been read.

6 - B brings CSTRBb high after CRDYb goes low.

7 - B drives the next byte on CDb(7–0) after CRDYb goes low.

8 - After a transmission line time delay, A sees CSTRBa go high.

9 - A brings CRDYa high after CSTRBa goes high.

10 - After a transmission line time delay, B sees CRDYb go high.

11 - B brings CSTRBb low after CRDYb goes high. Events 3 through 11 repeat twice for bytes 2 and 3 (asynchronous handshaking)

12 - B drives an undefined byte on CDb(7–0) after CRDY goes low.

The chronogram below shows the token exchange: the token transfer operation requires handshaking of signals through CREQ and CACK.

The token sequence transfer according to the chronogram is:

0 - Initially, A has the token and is idle.

1 - B wants to send data and requests the token by bringing CREQb low.

2 - After a transmission line time delay, A sees the token request when CREQa goes low.

3 - After a type 1 delay from CREQa falling, A releases token ownership and acknowledges the request by bringing CACKa low.

4 - After a transmission line time delay, B sees the acknowledgement from A when CACKb goes low.

5 - A switches CRDYa from high impedance to high after CACKa falling.

6 - A puts CDa(7–0) in high impedance after CACKa falling.

7 - B switches CSTRBb from high impedance to high after CACKb falling.

8 - B brings CREQb high after a type 1 delay from CACKb falling.

9 - After a transmission line time delay, A sees CREQa go high.

10 - A switches CREQa from high impedance to high after receiving a high on CREQa.

11 - A brings CACKa high after CREQa goes high.

12 - A puts CACKa in high impedance after CREQa goes high and after CACKa goes high.

13 - A puts CSTRBa in high impedance after CREQa goes high.

14 - B puts CREQb in high impedance after CREQb goes high.

15 - B switches CACKb from high impedance to high after CREQb goes high.

16 - B puts CRDYb in high impedance after CREQb goes high.

17 - B switches CDb from input to output after CREQb goes high and starts driving an undefined value.

18 - B drives the first byte onto CDb(7–0) on H1 rising (plus analog delay) after CREQb goes high.

19 - B brings CSTRBb low on the second H1 rising (plus analog delay) after CREQb rising.

20 - After a transmission time delay, A sees the first byte on CDa(7–0).

21 - After a transmission time delay, A sees CSTRBa go low, signaling valid data.

22 - A reads the data and then brings CRDYa low.

The communication port interface from TI is the Sundance’s comport interface. More details are described in the TI C40 user guide.


Electrical

All signals are LVTTL.

All control signals are active low.


Sundance Digital Bus

The Sundance Digital Bus (SDB) interface is described in the Sundance help file.

The SDB interface is fully bidirectional and can transfer 16-bit data, to and from the TIM, at 200 MB/s.

Each SDB provides 16 data lines, a clock and a clock-enable signal and two other control signals for the bus arbitration in a bidirectional application.

There are two SDB interfaces:

  • 16-bit interface

  • 32-bit interface, doubling the sampling rate (i.e. 400MB/s)

From a hardware point of view, the SDB interface has 16 or 32 data lines and 4 control lines.

  • Request: req

  • Acknowledge: ack

  • Clock: sdb_clk_io

  • Clock-enable: sdb_enable

  • Data: sdb_data(15:0) or sdb_data(31:0)

More details can be found in:

  • the SDB specification document for the 16-bit SDB interface,

  • the SHB specification document for the 32-bit SDB interface.


Physical layer

The Sundance digital bus provides a fast synchronous communication link between TIMs.

The following table describes the SDB connector interface.

Signal name | Description
Sdb_clk_io | SDB clock. The transmitter provides the clock. Req, Sdb_data and Sdb_enable signals are synchronous to this clock
Ack | SDB acknowledge. The interface activates this signal to indicate it releases the SDB bus upon receiving a REQ. It will also activate it to stop to the transmission when reception buffer is full
Req | Bus request. The interface activates this signal to request the use of the bus
Sdb_data[15:0] | SDB data bus
Sdb_enable | SDB data valid. The interface activates this signal to indicate it has placed a word on the data bus

These chronograms show you how the lines are driven fro both interfaces:

This chronogram shows a data transfer for a 16-bit interface:

The transmission is synchronous.

The transmitter sets the clock and the enable signal. A valid data is present on the bus at the rising edge of the clock when the sdb_enable signal is low

This illustrates the transmission for the SDB 16-bit interface. It shows the transmission of a 32-bit word and then this of three 32-bit words. The lowest half is sent first.

The receiver works with the clock of the transmitter. The dual port FIFOs enable to have independent clocks and so to read out the data at a different frequency.

Note: For a 32-bit interface, a full word is sent every rising edge of the clock. This doubles the data rate transfer (400MB/s).

These chronograms show a the token exchange:

For the bi-directional transmission two signals are used for the bus exchange: ack and req.

Reset: A “receiver_at_reset” must be connected to a “transmitter_at_reset” but the transmission can start in any direction.

Transmission: The transmitter drives the clock, the enable signal and the data to transmit and the ack signal to reply to the bus request. The receiver drives the req signal to request a bus exchange and the ack signal to interrupt the transmission.

Request: The receiver can, at any time, request the bus. The transmitter will give the bus as soon as its direction is low.

Exchange: The transmitter acknowledges the request made and frees the bus. The receiver becomes the transmitter and can then use the bus.

Time | Interface A | Interface B
T0 | Receiving | Transmitting
T1 | The user sets direction high to ask the bus. The interface requests the bus setting req high. The interface is still receiving | Transmitting
T2 | Receiving | The user allow the bus exchange setting direction low. The interface acknowledges the request setting ack high. The interface is still transmitting
T3 | The interface sets req low. The interface is still receiving | Transmitting
T4 | Receiving | The interface sets ack low and stop driving the bus
T5 | Transmitting | Receiving

The input and output busses are independent so the transmission is possible while emptying the FIFO containing the data previously received.

The number of clock cycles to exchange the bus depends on the clock frequency of both interfaces.


Rocket-IO Serial Link

The Rocket Serial Link (RSL) is a serial interconnection standard that is capable of data transfer speeds of up to 2.5Gbit/s per serial link. Up to four of these links can be combined to form a Rocket Serial Link Communications Channel (RSLCC) that is capable of data transfer up to 10Gbit/s.

Each RSL is made up of a differential Transmit and Receive pair. A single Rocket Serial Link is thus a full-duplex link and can transfer data at up to 2.5Gbit/s in either direction at the same time. The transmission clock is recovered from the data stream, leaving the link as a fully independent communications link that requires no additional control or data signals.

The RSL standard is based on the RocketIO transceiver core found on Xilinx Virtex-II Pro FPGAs. These silicon integrated transceiver cores handle the serialization / de-serialization of the data stream as well as certain low level management functions.

The interface is based on Xilinx’s Aurora protocol that is fully described by them. On one side is the serial interface going to the next TIM and on the other side is the user interface, which is a standard interface as well from Xilinx, called the LocalLink interface. It is as well fully specified by Xilinx.

More information can be found in the RSL technical specification document.


Physical layer

Data width

The aurora interface has the option of 2 or 4 bytes per lanes. Only selecting 2 bytes per lanes allows the maximum clock frequency to be used. So the data width can be 16, 32 or 64 bits with 1, 2 or 4 lanes respectively.

The designs names are following Xilinx’s naming convention. (For example 201 means a 2 bytes interface on 1 lane)

The standard data width is 32 bit for the DSP so the 16-bit interfaces is provided with additional data width conversion (32 to 16 in output and 16 to 32 in input).

Reference clock (transfer speed)

The reference clock on both TIMs needs to be identical.

It can be from any FPGA I/O if it is below 100MHz or needs to be from special I/Os from dedicated low jitter crystals for higher speed (100-156.25).

Each Aurora design supports one clock architecture and should be selected according to the transfer speed required and the available on-board clock.

FIFO sizes

The FIFO sizes can be chosen freely except from the one used as a buffer as its size is directly linked to the interface latency to respond to the flow control messages.

Practically the buffer size needs to be bigger than 100 words to be able to support the flow control.

Input and output clocks

The design is made to allow independent read and write clocks. The speed of which will be a speed factor obviously.


Electrical

All signals are LVDS.


Global Bus

The global memory interface has been introduced by Texas Instruments in the C4x DSP series to manage data transfer between the DSP and the external memory. It consists of a 32-bit data bus, a 31-bit address bus and a set of control signals.


Physical layer

The global bus interface is Sundance implementation of the TI global memory interface. When connected to the PCI bridge of Sundance’s carrier boards, it gives access to PCI resources of the host system.

The differences between the TIM compliant Global Bus Interface and the Sundance global Bus Interface appears:

  • On the STRB1 line during a WRITE access on the Global Bus

  • On the STAT(0) line at the end of a transfer

Contrary to the TIM compliant specification, NSTRB1 doesn’t go high between back-to-back writes to disable the memory while the address changes.

Back-to-back writes are single-cycle accesses. NSTRB1 stays low during back-to-back reads. NSTRB1 goes high between a write and a read, and it frames the RNW1 transition. A read following a write on the same bus takes two cycles.

For bus accesses, these signals provide information about the access that is about to begin.
Status | STAT3 | STAT2 | STAT1 | STAT0
Idle | 1 | 1 | 1 | 1
STRB1 access, last access | 0 | 1 | 0 | 0
STRB1 access, data read | 0 | 1 | 0 | 1
STRB1 access, data write | 1 | 1 | 0 | 1

STAT0 will go low for the last access on the Global Bus, that it is a Read or a Write. For single accesses STAT0 goes low as well.

Signal | Type | Description | Value after reset | Idle status
CLKIN | I | A CLKIN line is available on the primary connectors, so a module may choose to take its clock from the motherboard and synchronizes the Global Bus transfers with the carrier board | NA | Ignored
ADDE | I | Address bus enable signal for global-memory interface. When high (set to 1), places address lines GA (30–0) in the high-impedance state | NA | Ignored
CE1 | I | Control signal enable for RNW1, STRB1, and PAGE1 signals. When high (set to 1), it places the corresponding RNW1, STRB1, and PAGE1 signals in high-impedance state | NA | Ignored
DATE | I | Data bus enable signal for global memory interface. When high (set to 1), places data lines GD(31–0) in the high-impedance state. Reads can still occur but writes cannot | NA | Ignored
PAGE1 | O/Z | Memory-page enable signal for STRB1 accesses | 0 | 0
H1 | O | Global Bus Clock. Maximum Frequency of 50MHz | NA | Ignored
RDY1 | I | Indicates external memory is ready to be accessed | NA | Ignored
RNW1 | O/Z | Specifies memory read (active high) or write (active low) mode | 1 | 1
STAT(3:0) | O | Four lines that define the status or function of the memory port | 1s | 1s
STRB1 | O/Z | Interface access strobe | 1 | 1
GA(30:0) | O/Z | Address bus. The address lines are always driven. They keep the address of the last access | Hi-Z | Hi-Z
GD(31:0) | I/O/Z | Data bus. These signals go to high impedance between write accesses | Hi-Z | Hi-Z


Comport