Wiki

Analog Devices Wiki

English
English
简体中文
简体中文
日本語
日本語
Руccкий
Руccкий
This version is outdated by a newer approved version.DiffThis version (11 Feb 2021 08:39) was approved by Istvan Csomortani.The Previously approved version (09 Feb 2021 18:34) is available.Diff

This is an old revision of the document!

Table of Contents

Partial Reconfiguration with FMCOMMS2

Introduction

Partial reconfiguration is a unique feature of Xilinx FPGAs, which offer the possibility to reprogram a well specified portion of the FPGA on the fly, without affecting the functionality of the remaining logic.

The purpose of this design is to showcase this feature and to present a framework of the design flow, without trying to deliver a fully optimized solution. The design is build upon the latest version of FMCOMMS2 reference design.

The following wiki page does not want to replace Xilinx documentations and application notes, which contains more detailed descriptions, suggestions and recommendations. It is highly recommended to examine all the docs provided by Xilinx. During the design process the following documentations and application notes were used:

Supported carriers

Mini-ITX board definition file can be found at http://zedboard.org/support/documentation/2056 .

Design Flow

The supported design tools are:

The used design flow is the Tcl-based non-project flow. All the design phases are created and executed in memory, and the user is responsible to generate reports, log files or save checkpoints, for later investigations.

All the important tcl processes, which defines the necessary design phases can be found in adi_prcfg_project.tcl script. In the picture below can be seen the flow chart of the used design flow.

The design consist of the following base stages:

  • Create the work space
  • Create and synthesis the static part of the design, the re-configurable part is defined as a black box
  • Create and synthesis every re-configurable logic
  • Load the static design with one of the re-configurable logic, and implement it
  • Repeat the previous step with every re-configurable logic
  • Verify the compatibility of the bitstreams

After every step the script make a checkpoint and generates and saves additional reports.

To build up the hdl project, the user should follow the same instructions as at any other reference design. The design do not require any additional library compilation, it should run with the same cores as the FMCOMMS2 reference design.

After the source ./system_project.tcl script was executed the work space will contain the following directory tree: 

  ./prcfg_static                      # files related to the static design
   |       |
   |       /checkpoints               # synthesis and route checkpoints
   |       +logs                      # log file after synthesis
   +prcfg_default                     # by-pass logic  
   |        |
   |        /bit                      # partial and overall bit streams (*.bit and *.bin)
   |        +checkpoints              # synthesis and route checkpoints
   |        +logs                     # log files after synthesis, place, route and optimization 
   |        +results                  # top_routed checkpoint, timing and utilization reports
   +prcfg_bist                        # BIST logic  
   |        |
   |        /bit                      # partial and overall bit streams (*.bit and *.bin)
   |        +checkpoints              # synthesis and route checkpoints
   |        +logs                     # log files after synthesis, place, route and optimization 
   |        +results                  # top_routed checkpoint, timing and utilization reports
   +prcfg_qpsk                        # QPSK modulation/demodulation logic  
   |       |
   |       /bit                       # partial and overall bit streams (*.bit and *.bin)
   |       +checkpoints               # synthesis and route checkpoints
   |       +logs                      # log files after synthesis, place, route and optimization 
   |       +results                   # top_routed checkpoint, timing and utilization reports
   +sdk_export                        # contains the hardware specification file for the SDK project
   |
   +verify_design                     # contains the result of the bit stream verification

The script is saving a design checkpoint after every critical step in the design flow, giving the possibility to revert or jump back, if something goes wrong. For example if the user want to go back and examine the synthesis of the static design, simply need to write the following command into the tcl console: 

open_checkpoint ./prcfg_static/checkpoints/synth_static.dcp

By default, the script run all the necessary design flow stages (synthesis, implementation, logic verification and so on) in order to get a valid bitstream. There is a possibility to define which stages we want to run, by modifying the value of the following variables, on the script called /<board_name>/system_project.tcl : 

# activate/deactivate different flow stages
set runInit     1
set runSynth    1
set runImpl     1
set runPrv      1
set runBit      1

But need to keep in mind, each stage is depending on the prior stages.

Partial Reconfiguration Logic

In the hdl design of the FMCOMMS2, the re-configurable portion is defined in the RX/TX data path, between the AD9361 IP core and TX/RX DMAs, given the possibility to implement different type of modulation schemes, and to change these modulations, while the system is running.

Initially the top of the PR module is instantiated on the top of the design as a black box. The prcfg_setup.tcl script make sure that the FIFO interfaces between the DMAs and device core are brought up to the top. The top of the PR is a generic hdl wrapper, were the TX and RX modules are instantiated.

Adding new PR logic to the design

When a new PR logic is defined, the user need to make sure, that the top modules (which should be named prcfg_dac.v and prcfg_adc.v) has the same interface as the already defined modules (Default, Bist or Qpsk). The new logic should be placed in the hdl/library/prcfg/[logic_name] directory, and should be add into the flow, by modifying system_project.tcl script.

More information about the used FIFO interface can be find in the ADI Reference Design HDL User Guide.

Predefined PR Logic

Currently the reference project supports three different PR logic, which can be implemented and loaded into the PR portion:

  • Default logic, which leaves the data intact, so the design will functioning the same way as a regular FMCOMMS2 design.
  • BIST logic, which contains several internal tone generator for testing purpose. The user can select between three different option by setting a register, on the register map.
  • QPSK logic, which contains a QPSK modulator and demodulator. The modulation and demodulation logic were generated using MatLab HDL Coder 3.3.

The user can interact with PR logic, using a control and a status registers. The table bellow present the definitions of this two register, in case of each logic.

Control Register [DEVICE_BASEADDR + 0x02E]
Default Not Used[31:0]
Bist Not Used[31:8] Tone generator[7:4] Channel[3:0]
QPSK Not Used[31:8] Data path[7:4] Channel[3:0]
Status Register [DEVICE_BASEADDR + 0x02F]
Default Not Used[31:8] PR_ID[7:0] = 0xA0
Bist Not Used[31:10] PN_ERR[9:9] PN_OOS[8:8] PR_ID[7:0] = 0xA1
QPSK Not Used[31:10] PN_ERR[9:9] PN_OOS[8:8] PR_ID[7:0] = 0xA2

Default Logic

This logic is loaded by default into the PR portion. It does not modify the data path, the system will functioning as the original fmcomms2 design. The default logic ID number is 0xA0.

Bist Logic

This logic contains several internal tone generators for testing purposes. The user can select between the generators by setting up the Tone generator bits of the Control register. The BIST logic ID number is 0xA1.

The available configurations:

  • 0x0 – Default, pass through configuration
  • 0x1 – Internal sine tone generator (with a frequency of fs/8)
  • 0x2 – Internal PRBS generator
  • 0x3 – Internal pattern generator (alternating 0x5555 and 0xAAAA)

In the receiver side a PRBS monitor checks the received signal, and save the values into the PN_ERR and PN_OOS of the Status register. Note that, if the PRBS generator/monitor is used, the device should be in Digital Loopback mode.

QPSK Logic

The QPSK modulator and demodulator used in this logic, were generated by the MatLab HDL coder. The qpsk logic ID number is 0xA2. The below simulink model was used, to generate the hdl files. The model source file can be found in the hdl git repository.

In the block diagram below can be seen how these modules were integrated into the QPSK logic. The red blocks are representing the verilog modules, which were generated by the HDL Coder.

The available configurations:

  • 0x0 – Default, pass through configuration (bypass the modulation/demodulation)
  • 0x1 – Internal PRBS generator, the sequence is modulated and sent to the device in the transmitter side, and demodulated on the receive side.
  • 0x2 – Data from the DMA, user can send data from the memory.

In the receiver side a PRBS monitor checks the received signal, when the actual configuration is 0x1, and save the values into the PN_ERR and PN_OOS of the Status register. In PRBS mode Digital Loopback should be used.

Downloads

Test the design using a Linux image

To create or update SD card in order to test the reference design, the user should follow these steps below:

  1. Create and SD card from source by following the instructions from here, or update an existent SD card by following the instructions from here.
  2. Make sure that the BOOT partition of the SD card, contains the correct BOOT.bin, device tree and uImage. (To create the BOOT.bin the user should use config_default.bit bit file)
  3. Copy the partial bit streams to a known location of the file system.
  4. Boot up the Linux.
  5. If the PR project is supported by the IIO oscilloscope, the PR plugin will be loaded automatically (wiki page of the PR plugin). If not, follow the instruction above to update the SD card and/or make sure that the correct bit file was used.

Reconfigure the FPGA from Linux

The user can update the re-configurable portion of the FPGA, by using the Partial Reconfiguration plugin of the oscilloscope. The plugin does the following two steps, after the user specifies the partial bit-stream:

  1. set the device attribute called is_partial_bitstream to 1
  2. write the generated partial bin file to the PCAP configuration interface (/dev/xdevcfg).

The function, which do the update of the PR portion can be found here.

A few recommendation for the IIO scope setup:

  • The transmit side should be on DAC Buffer Output mode
  • If PRBS is used the Digital Loopback should be enabled
  • Because the IIO scope is using data from the memory, the ADC side should be on pass through configuration (0x0), in this way the user can examine the modulated data
  • Use a higher sample count for the constellation plot

resources/fpga/docs/hdl/partial.1613029157.txt.gz · Last modified: 11 Feb 2021 08:39 by Istvan Csomortani

Page Tools