This design is showcasing the Xilinx FPGA's partial reconfiguration feature, in order to generate partial reconfiguration bit streams, an extra license is needed from the vendor. To find out more about this specific license please visit Xilinx's Licensing Solution Center.
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:
Mini-ITX board definition file can be found at http://zedboard.org/support/documentation/2056 .
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:
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:
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.
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.
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.
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 present the definitions of this two register, 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 will functioning as the original 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 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.
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:
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 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 bit-stream:
The function, which do the update of the PR portion can be found here.
A few recommendation for the IIO scope setup: