We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Adam Taylor’s MicroZed Chronicles, Part 108: Creating our hardware definition for SDSoC

by Xilinx Employee ‎11-16-2015 10:43 AM - edited ‎01-06-2016 10:56 AM (87,342 Views)


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_aresetn];

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:



Part 108 text box.jpg



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.




  • First Year E Book here
  • First Year Hardback here.



MicroZed Chronicles hardcopy.jpg 



  • Second Year E Book here
  • Second Year Hardback here



 MicroZed Chronicles Second Year.jpg




You also can find links to all the previous MicroZed Chronicles blogs on my own Web site, here.







by Observer cole.jepson
on ‎01-25-2017 02:08 PM

I have followed these  directions exactly by inputting the commands seen in the first picture into the tcl console of Vivado. I then generated the bitstream and exported it just like I would if I was using SDK. I then opened the SDx terminal and continued to follow the instructions by using cd to get to the parent folder of my project and then inputting the commands shown in the second picture. I keep getting the error seen in that picture. I've been stuck on this for the last few days and I am very frustrated because I essentially can't start doing any programming until this problem is resolved. I have tried uninstalling SDSoC and using an older version but I got the same error. The last picture is my bd from Vivado. Any help would be greatly appreciated!








by Observer taylo_ap
on ‎01-26-2017 09:53 AM



I think the issue might be the command if generate_targert {sdsoc} not generate_targert <sdsoc> as you have written 


It is hard to see in the images, that it is that 


Thanks for reading 


by Observer imranashraf
on ‎05-21-2017 04:11 AM

I have followed these steps, but I am getting the following error:


hsi% generate_target {sdsoc} [hsi::current_hw_design]
ERROR: [Hsi 55-1712] HDF /shares/bulk/iashraf/pynqboardWork/PYNQ/Pynq-Z1/vivado/base/base/base.sdk/system.hwh doesn't contain APFCC Platform file details


Why APFCC platform is not included or How can I include it in hdf? Any clue will be highly appreciated.

About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.