By Adam Taylor
While SDSoC comes with a number of predefined hardware platforms, it is often necessary to create our own customized platform that configures the PS and the PL how we desire it. Over the previous few blogs, we created a system that incorporates the Zynq SoC’s XADC. We will now pull that hardare definition into SDSoC so that we can use it as the base for future developments. It’s always useful to have an ADC available.
To define our own platform, we need the following:
- <platform_name>_hw.pfm – describes the platform’s hardware aspects
- <platform_name>_sw.pfm – defines the software elements’ locations, be it a standalone or linux design
- Vivado directory – Containing the <platform_name>.srcs folder and the <platform_name>.xpr project
- <OS>.bif – defines how to create the boot image
- Boot directory – contains the FSBL
Note, I found it easiest to use the same name for the Vivado project and block diagram and for the name of the new platform definition. For this example, to keep it simple and to demonstate the concepts, we will be using a standalone OS and SDSoC Version 2015.2.1.
We will use Vivado, the SDSoC Command Prompt, and SDSoC to create the files required above. The first thing we will do is create our design in Vivado and apply some properties to the project before we build it.
These properties ensure that Vivado can correctly output the information SDSoC needs about the platform. At the most basic level there are 6 properties that need to be applied as shown below:
set_param project.enablePlatformHandoff true;
set_property SDSOC_PFM.CLOCK_ID 0 [get_bd_pins /processing_system7_0/FCLK_CLK0];
set_property SDSOC_PFM.MARK_SDSOC true [get_bd_pins /processing_system7_0/FCLK_CLK0];
set_property SDSOC_PFM.MARK_SDSOC true [get_bd_pins /rst_processing_system7_0_100M/interconnect_areset n];
set_property SDSOC_PFM.MARK_SDSOC true [get_bd_pins /rst_processing_system7_0_100M/peripheral_aresetn] ;
set_property SDSOC_PFM.MARK_SDSOC true [get_bd_pins /rst_processing_system7_0_100M/peripheral_reset]
When you enter these commands, be sure to use the names of the blocks exactly as they appear in your design and not as shown above (e.g. replace rst_processing_system7_0_100M with the actual name of your reset module).
Once these are added, we can reset and generate the output products, create the bit stream, and export the project as we would for any norrmal SDK project.
The next step differs from just creating an SDK project. The first thing we need to do is open an SDSoC Command prompt. We will use this command prompt to first change the directory to the top level of the Vivado project we are working in and then open HSI:
Once HSI is open, we need to load the exported design. It’s available under the <project_name>.sdk folder. We do this using the open_hw_design command:
The next command creates the <platform_name>_hw.pfm file. This file will contain more information than the PFM created by the previous ccommand under the SDK folder. It will also create two tcl files:
We simply rename the .pfm file at this point to include _hw at the end of its name. This underscored suffix distinguishes the existing .pfm file from the software definition we are about to create.
However before we do that, the new platform will need to know more about the Vivado design. So, we create a new directory called Vivado and underneath that directory we copy and paste the Vivado project file <project>.xpr and the sources directory <project>.srcs file:
Finally, the last thing we need to create are the software pfm file, as we are using a standalone OS and not linux (which would require a updated device tree, etc). This step is very simple. We can copy the same file from a pre-existing platform under <Xilinx Install>/SDSoC/2015.2.1/platforms. As this design is for the ZedBoard, I have copied and renamed the zed_sw.pfm. All I need to do is update the location of the library and linker scripts I am using as below:
I also copied the boot directory from the predefined Zed platform to the directory of my new platform. This boot directory contains the build first stage boot loader.
The final file to be created is standalone.bif, which informs SDSoC where the boot directory resides. This information is needed for building SD Card images. Within your working directory you should now have the following:
With all this created (it may seem like a lot of work but it only really takes a few minutes) we can open SDSoC and use our new platform. When we select “new SDSoC application,” we will be presented with a dialog box that allows us to enter the project name and to select the type of board. Here is where we click “other” and point to the directory that contains our .pfm files and the other directories and files we just created.
Once this is completed, you will see that this SDSoC project looks just like any other SDSoC project. Within the project overview, you will also notice that only the clocks you enabled in your Vivado design are available and the platform will point to your designated directory.
At this point, it is best to create a simple application and build the project to ensure that everything is as expected and that SDSoC will generate the SD Card files as required.
Having followed the above steps I had no problems. I double-checked the report, which showed that the build had indeed included the XADC as defined by the platform design:
This means next time we can start using our new platform definition. Until then…
If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.
You also can find links to all the previous MicroZed Chronicles blogs on my own Web site, here.
