By Adam Taylor
As I described last week, we need to a platform to fuse Python and SDSoC. In the longer term, I want to perform some image processing with this platform. So although I am going to remove most of the logic from the base design, we need to keep the following in the hardware to ensure that we can correctly boot up the Pynq board:
- SWSled GPIO
- Btns GPIO
- RGBLeds GPIO
- Block Memory – Added in the MicroZed Chronicles, Part 158
We will leave the block memory within the design to demonstrate that the build produced by SDSoC is unique and different when compared to the original boot.bin file. Doing so will enable us to use the notebook we previously used to read and write the Block RAM. However this time we will not need the overlay first.
Stripped Down Vivado Platform
As we know by now, we need to have two elements to create an SDSoC hardware definition and a software definition. We can create the hardware definition within Vivado itself. This is straightforward. We declare the available AXI ports, clocks, and interrupts. I have created a script to do. It’s available on the GitHib repository. You can run this in the command line of the TCL console within Vivado.
The software definition will take a little more thought. Because we are using a Linux-based approach, we need the following:
- uImage – The Pynq Kernel
- dtb – The device tree blob
- elf – The first-stage boot loader
- elf – The second-stage boot loader
- bif – Used to determine the boot order
We can obtain most of these items from the Pynq Master that we downloaded from GitHib previously under the file location:
Within this directory, you can find the FSBL, device tree, Uboot, and a boot.bif. What is missing however is the actual Linux kernel: the uImage. We already have this image on the SD card we have been running the PYNQ from recently. I merely copied this file into the SDSoC platform directory.
With the platform defined, we can create a simple program that does not have any accelerators and we can use SDSoC to build the contents of the SD Card. Once built we can copy the contents to the SD Card and boot the PYNQ. We should see the LED’s flash as normal when the Pynq is ready for use.
We should be able to access the BRAM we have left within the design using the same notebook as before, but with the overlay section commented out. You should be able to read and write from the memory. You’ll should also check to see that if you change the base address from the correct address, the notebook will no longer work correctly.
Having proved that we can build a design without accelerating a function, the next step is to ensure that we can build a design that does accelerate a function. I therefore used the matrix multiply example to generate a simple example that shows how you to correctly use the platform to accelerate hardware. This is the final confirmation we need to confirm that we have defined the platform correctly.
Creating a new project, targeting the same platform as before, with the example code, and targeting the generation of a shared library produced the following hardware build in Vivado:
MMult hardware example as created by SDSoC
Clearly, we can see the addition of the accelerated hardware.
All that is needed now is to upload the bit, tcl, and so files to the PYNQ and then write a notebook to put them to work.
Code is available on Github as always.
If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.
All of Adam Taylor’s MicroZed Chronicles are cataloged here.
via Xcell Daily Blog articles http://ift.tt/2fBJIws
December 12, 2016 at 08:07PM