Migrate SysGen Model in IDS to Vivado

Both IDS and Vivado Design Suite include System Generator (SysGen) for DSP. However, SysGen models created in IDS may not be compatible in Vivado because some design blocks in IDS SysGen may have different versions in Vivado or may not even be supported. SysGen in IDS 14.5/Vivado 2013.1 has a new "Model Upgrade" feature that will make migration of SysGen model from IDS to Vivado a lot easier. A couple of things to keep in mind when migrating:

1. Vivado only supports 7 Series (Virtex7, Kintex7, Artix7), Zynq, and newer device families.
2. Not all blocks om Xilinx BlockSet can be upgraded. Non-upgradable blocks need to be removed.

The migration is a two-step process:

1. Run IDS SysGen: upgrades all blocks to the latest version in IDS SysGen. 
2. Run Vivado SysGen: upgrade latest versions of all blocks in IDS SysGen to the latest versions in Vivado SysGen.

Upgrade Model in IDS SysGen:

1. Open the model in IDS SysGen
2. Open the "Properties" window of "System Generator". 
3. Select a 7 series or Zyqn device is selected as the "Compilation" target
4. Click the "Model Upgrade" button (Figure 1)
5. A "Upgrade Status Report" window (Figure 2) will popup showing versions of blocks used in the current model, available versions for those blocks in the current SysGen version, and if they are upgradable (manual connection may be required) or replaceable (upgraded block will be automatically connected by the tool).
6. Click "Upgrade the model" at the top of the report to upgrade the entire model or "Upgrade" in the "Perform Upgrade" column for each block to upgrade the corresponding block
7. Go back to SysGen model and manually remove incompatible blocks.
8. Save the upgraded model in IDS SysGen

Upgrade Model in Vivado SysGen:

1. Open the upgraded model above in Vivado SysGen
2. Right click an empty area on the model and select  "Xilinx Tools->Upgrade model" (Figure 3)
3. Save the model once the upgrade is done.

Figure 1. Model Upgrade button on IDS SysGen token

Figure 2. Upgrade Status Report in IDS SysGen

Figure 3: Upgrade model in Vivado SysGen

Floating Point Algorithm Development Made Easy in System Generator

System Generator 13.3 added support for bit and cycle accurate, single, double and custom precision-floating-point on many blocks in the Xilinx Blockset. It now has a new "Floating-Point" library under "Xilinx Blockset" in the "Simulink Libary Browser", which lists all blocks supporting floating point numbers (see the "Floating Point Library in Xilinx Blockset" snapshot below).

SysGen xlGenerateButton function example

As described in SysGen Reference Guide (view all Xilinx documents in Document Navigator), the xlGenerateButton function provides a programmatic way to invoke the System Generator code generator. The syntax is
    status = xlGenerateButton(sysgenblock)

This looks pretty straightforward: give it the full path name of the System Generator token in the design and let it run. The tricky part is that the actual name for the System Generator token has a space at the very beginning (i.e. " System Generator"), which must be included in the full path name of the SysGen token. In general, when in doubt, you can use the "gcb" function to get the full hierarchical path name of any selected block in a model. In this particular example (download the model and m script here), below are the steps to get the full path name of the System Generator token and the snapshot of the output:

1. Open the model system_period_test 
2. Select the System Generator token by clicking on it
3. Go to the command window and run gcb, which will return the path name

 You can now simply start the generation by running the command below:
    xlGenerateButton('system_period_test/ System Generator')

FFT v8.0 AXI with scaled output

The output of the FFT core can be set to "Scaled" to save some logic resources if the full precision is not required. A few things are worth mentioning to get the scaling to work:

SysGen Example of FFT v8.0 with AXI

Starting in IDS 12.3, most, if not all, new/upgraded Xilinx IP cores will only use AXI as user interface. For FFT v8.0 specifically, it provides AXI4-Stream interfaces for input/output data and control. The AXI4-stream interface is a lot simpler than memory mapped AXI4 interface. It uses basic handshake between the master and slave as shown in the snapshot below from the FFT v8.0 Data Sheet (note that all AXI IP cores have separate data sheets than the non-AXI versions). The key thing to remember is that the AXI payload is only transferred when both TVALID and TREADY are high.

I updated the SysGen example in the blog FFT results from Matlab fft, Bit Accurate C model and SysGen FFT block with FFT v8.0 core to show the use of  AXI4 stream interface. Below is the updated SysGen model:

The updated SysGen model and m file can be downloaded from here. Again, you will need to download the bit accurate model from FFT core web site yourself to run fft_compare.m script.

DDS in System Generator: how to set up periods?

If you use DDS Compiler in System Generator, you will notice there are 4 clock periods you need to deal with (circled in red in the snapshot below). This can be confusing for first time users. Hopefully this blog can clear up some of the confusions.

1. FPGA clock period (ns): only used for FPGA synthesis and implementation. This value does NOT affect simulation in Simulink (i.e. it will NOT affect output frequency of the DDS block).
2. Simulink System Period: only used in Simulink simulation. This is the lowest sampling period (highest sampling frequency) among all blocks in the model. There is no significance in its absolute value as long as the sampling periods of all other blocks are multiple of the Simulink System Period. Usually it is set to 1 to keep everything simple. (e.g. every tick in a scope is 1 clock cycle).
3. DDS System Clock (Mhz): It's used to calculate the phase increment for DDS block (see the DDS datasheet for details). Set it to match the FPGA clock period (i.e. DDS System Clock (Mhz) = 1/FPGA clock period).
4. Explicit Sample Period: This is the sample period used for the DDS block. IMPORTANT: if you set Simulink System Period to anything other than 1, "Use explicit period" MUST be checked and "Explicit Period" set to the same value as Simulink System period. Otherwise, Simulink will use the sample period of 1 for the DDS core and the output frequency will be wrong. This is likely a bug.

 Let's use a simple model (download the model for test1 here) below to show how all these periods play together in SysGen. The clock frequency of the SineGen block is 1/100th of the Simulink System Period (or 1MHz for a 100MHz clock input).

Test1:
FPGA clock period (ns) = 10
Simulink system period = 1
DDS System Clock (MHz) = 100
Use Explicit Sample Period checked and Explicit Period = 1
DDS Output (MHz) = 1

As shown in the scope below the DDS output matches the SineGen output:

Test2:
FPGA clock period (ns) = 10
Simulink system period = 0.1
DDS System Clock (MHz) = 100
Use Explicit Sample Period checked and Explicit Period = 0.1
DDS Output (MHz) = 1

As shown in the scope below the DDS output matches the SineGen output. Note that the Simulink system period is now 1/10th of the period in Test1, so there are 10x more clock cycles in this test with the same simulation time.

Test3:
FPGA clock period (ns) = 10
Simulink system period = 0.1
DDS System Clock (MHz) = 100
Use Explicit Sample Period unchecked
DDS Output (MHz) = 1

As shown in the scope below the DDS output frequency is 1/10th of SinGen output. The incorrect DDS output frequency is caused by that when "Use Explicit Sample Period" is unchecked Simulink use a sample period of 1 for the DDS block. So it's very important to check this checkbox and set the explicit period to match the Simulink system period if it's not 1. It's worth mentioning that for sampling frequency related issues it's very helpful to turn on "Sample Time Display" (under Format menu) and then update the diagram by pressing CTRL-D. You can easily see if the sample time used for a particular is correct with sampling time displayed on all signals.

FFT results from Matlab fft, Bit Accurate C model and SysGen FFT block

The usage of the FFT core is straightforward, however, it does have a lot more knobs to turn compared to a simple fft() function in Matlab. Sometimes when the output from the FFT core doesn't match Matlab fft() result you start to question if there is a bug in the FFT core. I will use a simple example here hopefully to

• provide some assurance that the result from the FFT core match well with Matlab fft() function and FFT bit accurate C model
• provide a starting point so you can look at configurations as well as timing of control and data signals of the core in case you didn't have time to read the FFT core data sheet

Below is the SysGen model that uses a 256-point FFT with pipelined streaming IO and unscaled output in natural order. The input vector is a simple ramp (-128:127)/128 in fixed 16.15 format.

The waveform below shows the FFT signals at the beginning of the simulation in WaveScope (a great tool in Xilinx Blockset for debugging, by the way). Note that in FFT v7.0 and newer, there is no longer a requirement of 3 cycle offset between xn_index and xn_re/xn_im inputs.

The waveform below is at the end of FFT computation and data start to unload. Note that xk_index is incrementing as the core output is in natural order.

The simulation results are collected in workspace. A m script is then run to compare the results from Matlab fft(), FFT bit accurate C model, and the Simulink simulation. Below is an overlay plot showing all three outputs, where the difference is negligible.

The script also prints all elements of outputs side by side for easy comparison.


idx    Matlab       Bit Accurate SysGen
0      1.000000     1.000000     1.000000
1      81.489376    81.489504    81.489595
2      40.747756    40.747746    40.747868
3      27.168581    27.168709    27.168739
4      20.380016    20.380048    20.380078
5      16.307697    16.307667    16.307587
...
251    16.307697    16.307667    16.307545
252    20.380016    20.380048    20.380017
253    27.168581    27.168709    27.168495
254    40.747756    40.747746    40.747960
255    81.489376    81.489504    81.489687

In case you want to play with the example design, you can download it from here. You will need to download the bit accurate C model from FFT core web site yourself because it requires registration.

SysGen: Create New HWCOSIM Target with NMM Ports

Hardware Co-Simulation (HWCOSIM) is a great feature in System Generator (SysGen) that allows users to run the full or part of a SysGen design on the FPGA and increase the simulation speed dramatically. SysGen already includes HWCOSIM plugins for commonly used DSP demo boards. Users can easily use the SysGen Board Description Builder (SBDBuilder) to create new HWCOSIM plugins for unsupported boards or unsupported features (for example non-memory mapped or NMM ports) on existing boards. Below are  step-by-step instructions on how to create a new HWCOSIM plugin with NMM ports using ML506 as an example.

Step 1: Open "System Generator" properties window and select "New Compilation Target".

Step 2: The SBDBuilder window pops up.
Board Name: use a descriptive name so you know what the target is later.
System Clock Frequency/Pin Location: enter the actual clock frequency and pin location for your board.
JTAG Options Boundary Scan Position: the position of the target device in the JTAG chain. You can use IMPACT to help fill this in (see a snapshot below for the JTAG chain detected by IMPACT). As shown in the JTAG chain snapshot, the target device xc5vsx50t is the 5th in the chain.
JTAG Options IR Lengths: click the "Detect" button next to it auto-fill it.
Target Devices: click "Add" button to select the target device.

Step 3: Click "Add" button in the "Non-Memory Mapped Ports" section to add NMM ports for HWCOSIM. This brings up the "Configure a Port" window below. Enter a port name, select port direction, Pin LOC and select PULLUP or PULLDOWN if needed. Click "Add Pin" button and the newly added pin will show up in the Pin List below. Click "Save and Start New" button if you want to add more pins or click "Save and Close" if you are done adding NMM ports.

Step 4: The SBDBuilder with all information entered is shown below. Click the "Install" button to install the new board configuration to the SysGen plugins directory.

Step 5: A window with tokens for the NMM ports will pop up once the installation is complete.

Step 6: Save the library with the NMM port tokens and they can now be used in your SysGen model like any other SysGen block. A test model is shown below.

 Step 7: Open "System Generator" properties window again and now you should see the newly created board "ML506 JTAG NMM" in the HWCOSIM target list. Select it as the compilation target.

Step 8: That's it. The rest of steps to use the new compilation target are the same as any other HWCOSIM. The only difference is that Simulink no longer has control/visibility of the two NMM ports. They are now implemented as IOs on FPGA. In this example, while the simulation is running, if you toggle the GPIO SW1 on the board, it will turn on/off the GPIO LED0.

IFFT in System Generator

The FFT block in Xilinx Blockset can be used to calculate both DFT and IDFT because the two equations are almost identical:

By default, the FFT block is configured to calculate DFT. The setup and timing of control/data signals for IDFT are the same as DFT except for two things:

1. The FFT block needs to be set up for IDFT by setting fwd_inv_we signal to 1 and fwd_inv signal to 0 before the start of the transform 
2. The FFT output needs to be manually scaled to account for the factor 1/N in Equation 2 above. The scaling can be done either by using the scaling schedule input or shifting the FFT output if the FFT block is set to "unscaled".

The picture below shows the timing of control/data signals at the beginning of a data frame.

Now let's use a simple 8-point IDFT example to show how everything is put together. Below is the IDFT calculation of a test vector xn_re in Matlab:

>>xn_re=[0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8];
>>ifft(xn_re)
ans =
Columns 1 through 5
0.4500  -0.0500-0.1207i  -0.0500-0.0500i  -0.0500-0.0207i 0.0500          

Columns 6 through 8
-0.0500+0.0207i  -0.0500+0.0500i  -0.0500+0.1207i

The idft_test simulink/sysgen model for the 8-point can be downloaded here. The model includes a block called WaveScope, which is a "hidden" gem in System Generator for debugging SysGen designs, especially for hardware engineers who are used to viewing waveforms in HDL simulators.

The picture below shows the waveform at the beginning of the simulation in Wavescope. fwd_inv_we=1 and fwd_inv=0 for 1 cycle to set up the block for IDFT. Also the scale_sch is set to "010101" at the beginning to scale the FFT result down by 8 (the 1/N factor in Equation 2).

The picture below shows the waveform in Wavescope at the end of simulation, which shows that the xk_re and xk_im outputs when dv=1 match the Matlab results above when taking the quantization errors into account.