In the previous blog we used Vivado to create an AXI4 peripheral and to generate a bit file. Having created the hardware components of the design, we now need to export it to our SDK design so that we can write software to drive it.
The first step is to open the current implementation within Vivado and then export the hardware to SDK. (You will get a warning if SDK is already in use when you attempt to export the hardware.) If you don’t export the hardware to SDK, the next time you open SDK, the hardware definition and the board support package will need to be updated or you won’t be able to use them.
It is also necessary to update the repositories defined within the design to include the IP repository that contains the peripheral. To do this we select the Xilinx tools option and then repositories and add the new repositories as either local or global. For this example I have chosen local.
Add in the peripheral directory created by Vivado and rescan the repositories. We can now re-build the project to recreate the files needed in the BSP to support software development.
Once the re-build is completed, open the xparameters.h file (within the BSP include files) to see the address space dedicated to the new AXI4 peripheral:
The next step is to open the System.MSS file and customise the BSP to use the drivers generated in the peripheral creation process instead of the generic drivers.
Re-building the project ensures that the driver files are loaded into the BSP. This is a very helpful step because these files also include a simple self-test program that you can use to test the that the software interface to the peripheral is correct before you start using it for more advanced things. Using this test program also demonstrates that we have correctly instantiated the Hardware in Vivado.
Under the BSP included within the libsrc you will see a number of files for the new AXI4 peripheral. These files allow you to read and write to the peripheral just as you do with the native peripheral devices such as the XADC and GPIO, which we have been using previously in other blog instalments.
For this simple example, the file adams_perihperal.h contains three functions we can use to drive the new peripheral. (Bonus points if you can spot my spelling mistake)
With the exception of the self-test function, the read and write functions are mapped to generic functions Xil_In32 and Xil_Out32, which are defined within Xil_io.h. However using the created functions enables more readable code as the peripheral being addressed is very clear.
For this example, we only have four registers within the peripheral so we will just use the self-test which will write and read to all of the registers and report a pass or fail. This test gives us confidence we have got the hardware and software environments correct and we can go on to more advanced functions once we define them in the peripheral module.
In the next blog we will be looking at how we can add in some functionality to the peripheral using VHDL code to offload functions from the Processing System and improve system performance.
Please see the previous entries in this MicroZed series by Adam Taylor: