High-Level Synthesis (HLS) has broken into the main stream with FPGA vendors and EDA companies offering tools which convert C, C++, System C and Matlab into FPGA bit streams. For hybrid SoCs, the same high-level language lets us design both the processor and the programmable logic and move design elements between the processor and FPGA fabric. In Part 1 of this series, we asked readers to select the algorithm for implementation with SDSoC. In part 2, we designed the FIR filter and the initial hardware in Vivado.

I was ready to create the SDSoC platform however, I then upgraded to the latest version of SDSoC 2015.4 and how we created the SDSOC platform changed so I had to go back to Vivado this time 2015.4.

Actually this was a stroke of luck as it enabled me to realized I could drive the SPI DAC straight from the PS MIO and not require the EMIO, also generating the SDSoC platform is much simpler in 2015.4 than it was in previous versions.

click for larger image



The SPI 1 port on the Zynq is connected to the PS Pmod (JE) on the ZedBoard, this make the build slightly simpler than using EMIO.

In prior versions we had to run a number of commands in Vivado to set up the design for export, declaring the clocks, resets and interrupts etc. Then we used the SDSoC terminal to generate a PFM file before this was renamed such that we could use it. It was all pretty straight forward but not as easy as it is now with 2015.4 now Vivado is used for all stages of generating the platform.

At the highest level what we to do to define a SDSoC Platform is

Define the clocks and their frequency available with the platform, these will be used for the accelerated function and the data moving network. Note as all interfaces are via AXI we can use different frequencies

Similar to the clocks we also need to declare the resets available within the hardware.

We need to declare the unused AXI ports (GP, HP and ACP) for specialist applications it is possible to share them but for this application we will keep it simple and just declare the unused ones.

The final requirement is the available PL to PS interrupts, these are used to communicate between the accelerated function and the communicating framework running in the software.

When we have finished our new hardware platform looks like this:

click for larger image



Entering the very simple commands in UG1146 (which is in the doc’s folder of your installation) in the Vivado TCL command line we can create one of the two platform definition files.

There are two definition files required for a SDSoC platform both are defined in XML, the first is the hardware definition generated by the steps above in Vivado. While the second is the software definition this one is much simpler than the hardware definition which is good as you have to write this one by hand or copy and modify an existing definition.

The reason for this is that the software definition depends upon the operating system we wish to use (standalone, FreeRTOS or LINUX) each one requires to be informed where the necessary libraries are located, boot configuration files and if LINUX the device tree blob. You can see an example software platform definition below.





Basic platform targeting the MicroZedBoard, which includes 1 GB of DDR3, 128 Mb QSPI Flash and a MicroSD card interface. More information at http://www.zedboard.org/products/microzed



xd:os=”standalone”

xd:includeDir=”arm-xilinx-eabi/include”

xd:bspconfig=”arm-xilinx-eabi/include/system.mss”

xd:ldscript=”arm-xilinx-eabi/lscript.ld”



/>

xd:os=”linux”

xd:bif=”boot/linux.bif”

xd:readme=”boot/generic.readme”

xd:devicetree=”boot/devicetree.dtb”

xd:linuxImage=”boot/uImage”

xd:ramdisk=”boot/uramdisk.image.gz”

/>

xd:os=”standalone”

xd:bif=”standalone.bif”

xd:readme=”boot/generic.readme”

/>



With the explanation on what is needed for our platform definition completed we can now move on to building the software and accelerating it I promise.