DSP Builder for Intel® FPGAs (Advanced Blockset): Handbook

ID 683337
Date 12/04/2023
Public
Document Table of Contents

7.1. DSP Builder Design Rules and Recommendations

Use the design rules and recommendations to ensure your design performs correctly.

Design Rules for the Top-Level Design

  • Ensure the top-level design has a Control block and a Signals block.
  • Ensure the synthesizable part of your design is a subsystem or contained within a subsystem of the top-level design.
  • Ensure testbench stimulus data types that feed into the synthesizable design are correct, as DSP Builder propagates them.
  • Ensure you place Interface > ExternalMemory and Avalon Memory-MappedSettings blocks only in the top-level design

Design Rules for the Synthesized Top-Level Design

  • Ensure your synthesized hardware top-level subsystem has a Device block.
  • Ensure you place some non-synthesizable blocks (from the Interface > MemoryMapped > Stimulus and Utillities > Testbench libraries outside the synthesized system.

Design Rules for the Primitive Top-Level Design

  • Ensure the primitive top-level subsystem contain a SynthesisInfo block with style set to Scheduled.
  • Ensure the Primitive subsystems do not contain IP blocks.
  • Only use primitive blocks in primitive subsystems and delimit them by primitive boundary blocks.
  • If using ALU folding, ensure the ALU Folding block is in the primitive top-level subsystem.
  • Route all subsystem inputs with associated valid and channel signals that are to be scheduled together through the same ChannelIn blocks immediately following the subsystem inputs. Route any other subsystem inputs through GPIn blocks.
  • Route all subsystem outputs with associated valid and channel signals that are to be scheduled together through the same ChannelOut blocks immediately before the subsystem outputs. Route any other subsystem outputs through GPOut blocks.
  • Ensure all primitive subsystem input boundary blocks (GPIn or ChannelIn) or output boundary blocks (GPOut or ChannelOut) are in primitive top-level subsystem.
    Note: Also Avalon-MM interface blocks can be subsystem schedule boundaries
  • Ensure the valid signal is a scalar Boolean signal or ufix(1).
  • Ensure the channel signal is a scalar uint(8)

Design Rules for Avalon-MM Interface Blocks

  • Place shared memory blocks inside primitive scheduled subsystem.
  • Ensure the RegField and RegBit blocks output type width exactly match the range you specify for these blocks through MSB and LSB parameters.
  • Ensure the specified ranges through MSB and LSB parameters fit within Avalon-MM word width set from Avalon Interfaces > Avalon Memory-Mapped Settings.
  • Ensure different instances of register blocks (RegBit, RegField, or RegOut) that map to the same Avalon-MM address specify disjoint ranges.
  • For shared memory blocks, ensure output data width matches or is twice the size of Avalon-MM data width set from Avalon Interfaces > Avalon Memory-Mapped Settings.
  • Locate the BusStimulus and BusStimulusFileReader blocks in the testbench, which is outside the synthesizable system.

Recommendations for your Top-Level Design

  • Create a Simulink project for your model file, libraries, and scripts.
  • Use workspace variables to set parameters, which allows you to globally organize and change them.
  • Use set-up scripts to set the workspace variables and clear-up scripts to clear them from the workspace afterwards.
  • Run set-up, analysis, and clear-up scripts automatically by adding them to the model callbacks.
  • Build a testbench that is parameterizable with system parameters such as sample rate, clock rate, and number of channels. Use the Channelizer block to create data in the valid-channel-data protocol.
  • Hierarchically structure your design into subsystems. A modular design with well-defined subsystem boundaries allows you to precisely manage latency and speed of different modules and achieve timing closure.
  • Save repeated subsystems as library blocks. Replace the design blocks with copies from the library.
  • Make library blocks configurable and self-modifying.
  • Create and use your own libraries of reusable components. Organize them into separate library files.
  • Use configurable subsystem blocks in libraries to switch implementations in place.
  • Build separate testbenches for library blocks
  • Keep block and subsystem names short, but descriptive. Do not use names with special characters, slashes, or that begin with numbers.
  • Use vectors to build parameterizable designs. DSP Builder does not need to redraw them when parameters such as the number of channels change. A design that uses a vector input of width N is the same as connecting N copies of the block with a single scalar connection to each.

Recommendations for Loops in Primitive Subsystems

  • Ensure sufficient sample delays (SampleDelay blocks) exist around loops to allow for pipelining
  • To determine the minimum loop latency, turn on Minimum Delay on the SampleDelay block
  • Simulink performs data type, complexity, and vector width propagation. Sometimes Simulink does not successfully resolve propagation around loops, particularly multiple nested loops.
  • If Simulink is unsuccessful, look for where data types are not annotated.
  • You may have to explicitly set data types. Simulink provides a library of blocks to help in such situations, which duplicate data types. For example, the data type prop duplicate block, fixpt_dtprop, (type open fixpt_dtprop from the MATLAB command prompt), which the control library latches use.
  • Avoid primitive subsystems with logic that clocked inputs do not drive, because either reset behavior determines hardware behavior or the hardware is inefficient.
  • Avoid examples that start from reset, as the design simulation in Simulink may not match that of the generated hardware. You should start a counter from the valid signal, rather than the constant. If the counter repeats without stopping after the first valid, add a zero-latency latch into this connection.
  • Avoid loops that DSP Builder drives without clocked inputs.