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 built 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:
Mini-ITX board definition file can be found at http://zedboard.org/support/documentation/2056 .
The supported design tools are:
The design flow that was used is the Tcl-based non-project flow. All the design phases are created and executed in the memory, and the user is responsible to generate reports, log files or save checkpoints, for later investigations.
All the important Tcl processes, which define 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 consists of the following base stages:
After every step, the script makes a checkpoint and generates and saves additional reports.
To build the HDL project, the user must follow the same instructions as with any other reference designs. The design does not require any additional library compilations, it should run with the same cores as the FMCOMMS2 reference design.
After the source ./system_project.tcl script is executed, the workspace 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 bitstreams (*.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 bitstreams (*.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 bitstreams (*.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 wants to go back and examine the synthesis of the static design, he/she simply needs to write the following command into the tcl console:
By default, the script runs 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, in 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.
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 types 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 makes 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, where the TX and RX modules are instantiated.
When a new PR logic is defined, the user needs to make sure that the top modules (which should be named prcfg_dac.v and prcfg_adc.v) have 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 added into the flow, by modifying system_project.tcl script.
More information about the used FIFO interface can be found in the ADI Reference Design HDL User Guide.
Currently, the reference project supports three different PR logic, which can be implemented and loaded into the PR portion:
The user can interact with PR logic, using a control and a status registers. The table bellow presents the definitions of these two registers, in case of each logic.
|Control Register [DEVICE_BASEADDR + 0x02E]|
|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|
This logic is loaded by default into the PR portion. It does not modify the data path; the system works as the original AD-FMCOMMS2 design. The default logic ID number is 0xA0.
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:
In the receiver side, a PRBS monitor checks the received signal, and saves 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.
The QPSK modulator and demodulator used in this logic, were generated by the MatLab HDL coder. The QPSK logic ID number is 0xA2. The following Simulink model was used to generate the HDL files. The model source file can be found in the HDL GitHub repository.
In the block diagram below, it can be seen how these modules were integrated into the QPSK logic. The red blocks represent the Verilog modules, which were generated by the HDL Coder.
The available configurations:
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.
To create or update an SD card in order to test the reference design, the user should follow these steps below:
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 bitstream:
The functions, which do the update of the PR portion can be found here.
A few recommendations for the IIO oscilloscope setup: