Skip to main content

Customer Login

This content is for Speedgoat customer only. Log in to see content.

Forgot your password?

Don't have a Speedgoat account? Create an account.

Documentation
CONTENTS

Speedgoat IO3xx DMA FPGA DDR Frame Buffer

Speedgoat IO3xx DMA FPGA DDR Frame Buffer — The Speedgoat IO3xx DMA FPGA DDR Frame Buffer block is used to transfer data with DMA from the FPGA DDR RAM to the CPU RAM and into the model or vice versa

Supported Modules

  • IO332-200k

  • IO333-325k, IO333-410k, IO333-325k-SFP, IO333-410k-SFP

  • IO334-325k

  • IO335-325k

  • IO342-1080k, IO342-1450k

Library

  • >> speedgoatlib_hdlCoder_IO3xx_user

Description

You may use up to one frame buffer block per FPGA module. There are three different timing concepts defined for the DDR FPGA RAM Frame Buffer block:

  • In a Classic DMA-driven data transfer engine, the goal is to avoid using CPU resources to move data. As such, the user does not actively wait for a transfer to complete, but rather reacts upon completion. In the case of the RAM Buffer, at time step t the transfer is initialized by the block. At time step t+1, a check is performed to ensure the transfer completed. The read data is then output (depending on the transfer type) and the next transfer is queued up. In classic mode, if strict error-checking is enabled, the block will stop the model execution if the engine fails to complete the transfer from time step t when time step t+1 is reached. If strict error-checking is disabled, the block will not stop the model execution, but will signal on the output port that the transfer failed to complete.

  • The Data Accelerator mode allows the completion of the transfer to be verified in a single time step. This allows, for instance, read values to be output and used in the same model execution step as when the transfer was triggered. The disadvantage of this mode is that since the CPU is actively waiting for the completion of the transfer, the TET will be prolonged. If data accelerator mode is being used, a timeout value for the transfer must be set. When this timeout value is reached, the transfer is cancelled. If strict error-checking is enabled and the timeout is reached, the model is stopped in an error state. Conversely, without error-checking, the failure to complete is simply signaled on the status port.

  • IRQs have timing behaviors identical to classic mode, except that the model execution will be driven forward when the transaction is completed. If the model is run using IRQ interrupts coming from this subsystem, then classic mode should be selected. Selecting a different mode for interrupt-driven operation will produce undefined results. The interrupt source can be selected in the generated model once run through the HDL Coder Workflow Advisor. Please select the Speedgoat IO3xx HDL Coder FPGA RAM Buffer in the Interrupt Setup block.

    For more information about the Interrupt Setup block, refer to the Speedgoat integrated Help or online documentation.

Ports

The ports of the DDR FPGA RAM Frame Buffer are dynamic, according to the directions and mode settings provided by the user.

In Ports
Data In

The Data In port supplies data to the write portion of the block. The size and data type will be forward propagated into the block. The standard data types of one to eight bytes long are allowed. If data types larger than 32-bits are used, first split them into smaller data types and bundle them as a two- (or more) dimensional matrix. Matrices of any size may be written to the data input port, though they will of course be flattened in the FPGA RAM into a vector of the base data type. A two-dimensional matrix will be stored in the RAM in column-major order. Generalizing, an N-dimensional matrix will be written to the RAM memory in N-major order. For instance, the three-dimensional matrix shown below would be written to the FPGA RAM in alphabetical order.

FPGA RAM Offset Write

Using this port, the offset from the base address in the RAM for the next write transfer is specified. Offsets should be chosen carefully so that they do not overrun the 2 GB FPGA RAM address space, as this will halt model execution in an error state. Offsets provided on this port will be aligned to 64 byte boundaries (i.e. 0x40, 0x80, 0xC0 and so on), so users are recommended to model accordingly. Due to the function of the DMA engine which is used for the data transfer, 0x2000 byte packets are written. If the write functionality is used, at least 0x2000 bytes will be written, though only the requested data will actually be read in from the block data input port. Care should be taken in modelling to avoid overwriting data that it still needed in the RAM.

FPGA RAM Offset Read

Using this port, the offset from the base address in the RAM for the next read transfer is specified. Offsets should be chosen carefully so that they do not overrun the 2 GB FPGA RAM address space, as this will stop the model execution in an error state. Offsets provided on this port will be aligned to 64-byte boundaries (0x00, 0x40, 0x80, 0xC0 and so on), so users are recommended to model accordingly. Due to the function of the DMA engine, which is used for the data transfer, 0x2000 byte packets are read out from the RAM. If read is used, at least 0x2000 bytes will be read, though only the requested data will actually be output on the block data output port.

Trigger Transfer

Some parametrization sets allow the model to electively trigger the buffer transfer. Setting this port to one will trigger a transfer as parametrized. The trigger and status ports are useful for larger, asynchronous data transfers which may span several model time steps.

Out Ports
Data Out

The Data Out port supplies data which has been read from the FPGA RAM to the rest of the model. The size and data type must be back-propagated into the block. These specifications should be provided by using the standard Signal Specification block. This block allows users to define the output data type and dimensionality. The data type is again limited to types of one to eight bytes, but the dimensionality of the signal is not limited. This port need not match the Data In port in either data type or size. The standard data types of one to eight bytes long are allowed. Matrices of any size may be read from the data input port, though they will, again, of course be flattened in the FPGA RAM into a vector of the base data type. A two-dimensional matrix will be stored in the RAM in column-major order. An N-dimensional matrix will be read from the RAM memory in N-major order, as in the write case. Please see the preceding section for details on how the values should be organized in the FPGA RAM.

Transfer Status

In some parametrization sets, the execution can continue despite a failed transfer. This port can be used in the model to respond to incomplete transfers. An output of one means the transfer completed. An output of zero means the transfer was not completed.

Parameters

Tab: General

The general parameter tab contains the basic parameters associated with the block. These parameters include: Device Index, a Polling Enable toggle switch, and a pull-down menu for selecting the direction of the transfer.

FPGA Module Identifier - Unique identifier for FPGA I/O module

1 (default) | n

Enter a unique number. This setting must match the setting of the corresponding design under test (DUT) subsystem generated. This is usually only relevant in a multi-module model, as otherwise the default value 1 is applied. The module identifier ordinal sequence will also correspond to the ordinal sequence of the modules' positions on the PCIe bus. In this way such modules of the same device type can be uniquely identified. For this reason, if multiple modules of the same type are installed in the target machine and one module is not in use within a given model, a bus and slot for the modules which should be used must be specified.

Directions

Read Enable | Write Enable | Read and Write Enable (default)

Use the direction pull-down menu to specify if you wish to perform a read, write or read/write transfer (Note: Read transfer is always performed).

Tab: Transfer Setup

This tab contains further specifiers which control the timing behavior of the Buffer Transfer more granularly. The parameters in this tab include a Strict Error-Checking toggle switch, a pull-down menu for selecting the Transfer Mode, and finally, depending on other parameters, a timeout value.

Strict Error-Checking

checked | not checked (default)

Use this toggle switch to select strict error-checking. If strict error checking is enabled, the block will stop the model execution if the engine fails to complete a single transfer within the set timing boundaries. If the buffer fails to transfer, the model is put into an error state, and an error message can be seen on the real-time target machine's screen which will explain the cause of the error. If strict error-checking is not used, the transfer trigger and status ports will be added to the block.

Timeout

time (us)

Set the maximum time for a data transfer in microseconds. This is only available for data acceleration mode. Setting the timeout longer than the model execution time step will cause the model to stop if the transfer takes longer than the model execution time step.

Transfer Mode

Classical | Data Accelerator (default)

Use this pull-down menu to set the transfer mode which is appropriate for the application. Two transfer modes are defined: "Classic" and "Data Acceleration". As seen in the timing diagram, in classic mode, the block outputs update one time step later, and in data acceleration mode, block outputs are updated in the same time step.

Target Screen Output

This section contains an overview of the output which may be seen on the target machine's display.

Model Start
Memory Allocation

The use of the frame buffer is associated with allocating large amounts of contiguous physical memory in the target machine. Depending on the complexity of the rest of the model, the real-time operating system may have difficulty allocating sufficient memory. In this case, the model will be stopped with one of the following error messages:

  • Failed to allocate space for the buffer pointer arrays!

  • Failed to allocate space for the DMA descriptor pointer array!

  • Failed allocating DMA pool!

The cause of all of these error messages is the failure to allocate sufficient system RAM. Reboot the target machine and try to run the model again. If this fails to resolve the issue, your target machine may have insufficient RAM for your model to execute correctly.

FPGA RAM Initialization

The FPGA DDR RAM must be initialized to use the RAM Buffer block. This operation fills the RAM with random data in order to initialize all sections of the RAM. If this step is not performed and an attempt is made to read an unused section of the RAM, an error condition will be generated. During initialization the following entries will be seen:

  • Initializing the FPGA DDR RAM.

  • N memory segments of M bytes need to be initialized.

  • ######....#

If the RAM initialization is not successful, there is a serious problem with the system. You will see the following error message:

  • Timeout during DDR Initialization.

If this error message displays, contact Speedgoat support.

Polling Mode Initialization

If polling mode is used, the polling must be registered with the operating system. If there is a conflict with another polling function, or if multiple blocks are attempting to use polling, the following error message may be displayed:

  • Failed Setting DMA Polling Function!

Model Outputs
Offsets

Care should be taken when setting the FPGA RAM address offsets. If the offset is too high in the range and a read or write operation causes the address to wrap past the end of the memory range, the following error messages may be displayed:

  • Requested read offset will overrun the FPGA RAM address space.

  • Requested Write offset will overrun the FPGA RAM address space.

Data Output

During model execution, the following error messages may display if there are problems with the hardware associated with the Frame Buffer block:

  • CDMA Polling Error: Polling function timeout!

  • CDMA Error: Engine not idle ...

  • CDMA Error: Timeout on data transfer!

    If these error messages appear, the model should be examined to see if an unrealistic amount of data is being requested for the model execution time (in the case of polling or strict error-checking). If this is not the case, please contact support.

    Read/write operations with the same offset can be performed. Data will be read, and then overwritten with the new data.

Performance

The following table shows typical performance numbers of the DDR FPGA RAM Frame Buffer transfer engine operating in Data Acceleration mode. The transferred size was 0x90000 bytes in each direction. Frame buffer transactions are highly asymmetric, with write transactions taking considerably more time than read transactions. As seen in the table, speed increases can be expected with higher design under test (DUT) clock settings. However, the speed bottleneck is not primarily formed by the FPGA interface, but rather by the PCIe system level architecture. Write transactions are not significantly improved with higher DUT clock rates. Since the buffer engine uses fixed transaction sizes of 0x2000 bytes, the larger a transaction is, or the closer it is to a multiple of this size, the more efficient it will be.

CDMA Engine Transfer Performance:

DirectionDUT Clock (MHz)Bit Rate (MBit/s)
READ1004610
WRITE1002020
READ/WRITE1002780
READ2005750
WRITE2002000
READ/WRITE2003070

Note: Care should be taken when combining the AXI4Master interface and the frame buffer, since they both use the DDR memory resource. As they may not access the memory simultaneously in the same direction, an incomplete AXI4 Master memory write should not be interrupted with a Frame Buffer write request. If such requests are made simultaneously, the results are undefined.