UPGRADE YOUR BROWSER

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!

The Zynq PS/PL, Part Three: Adam Taylor’s MicroZed Chronicles Part 23

by Xilinx Employee on ‎03-10-2014 10:30 AM (122,382 Views)

By Adam Taylor

 

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.

 

 

 Figure 1.jpg

 

 

 

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:

 

 

 Code Listing 1.jpg

 

 

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.

 

 

 Figure 2.jpg

 

 

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.

 

 

 Figure 3.jpg

 

 

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)

 

 

ADAMS_PERIHPERAL_mReadReg(BaseAddress, RegOffset)

 

ADAMS_PERIHPERAL_mWriteReg(BaseAddress, RegOffset, Data)

 

XStatus ADAMS_PERIHPERAL_Reg_SelfTest(void * baseaddr_p);

 

 

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.

 

 Code Listing 2.jpg

 

 

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:

 

The Zynq PS/PL, Part Two: Adam Taylor’s MicroZed Chronicles Part 22

 

The Zynq PS/PL, Part One: Adam Taylor’s MicroZed Chronicles Part 21

 

Introduction to the Zynq Triple Timer Counter Part Four: Adam Taylor’s MicroZed Chronicles Part 20

 

Introduction to the Zynq Triple Timer Counter Part Three: Adam Taylor’s MicroZed Chronicles Part 19

 

Introduction to the Zynq Triple Timer Counter Part Two: Adam Taylor’s MicroZed Chronicles Part 18

 

Introduction to the Zynq Triple Timer Counter Part One: Adam Taylor’s MicroZed Chronicles Part 17

 

The Zynq SoC’s Private Watchdog: Adam Taylor’s MicroZed Chronicles Part 16

 

Implementing the Zynq SoC’s Private Timer: Adam Taylor’s MicroZed Chronicles Part 15

 

MicroZed Timers, Clocks and Watchdogs: Adam Taylor’s MicroZed Chronicles Part 14

 

More About MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 13

 

MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 12

 

Using the MicroZed Button for Input: Adam Taylor’s MicroZed Chronicles Part 11

 

Driving the Zynq SoC's GPIO: Adam Taylor’s MicroZed Chronicles Part 10

 

Meet the Zynq MIO: Adam Taylor’s MicroZed Chronicles Part 9

 

MicroZed XADC Software: Adam Taylor’s MicroZed Chronicles Part 8

 

Getting the XADC Running on the MicroZed: Adam Taylor’s MicroZed Chronicles Part 7

 

A Boot Loader for MicroZed. Adam Taylor’s MicroZed Chronicles, Part 6 

 

Figuring out the MicroZed Boot Loader – Adam Taylor’s MicroZed Chronicles, Part 5

 

Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4

 

Zynq and MicroZed say “Hello World”-- Adam Taylor’s MicroZed Chronicles, Part 3

 

Adam Taylor’s MicroZed Chronicles: Setting the SW Scene

 

Bringing up the Avnet MicroZed with Vivado

 

 

 

 

Comments
by Visitor lphilippe.b
on ‎07-15-2014 12:14 PM

Hi,

First of all, thank you for this blog, it helps me a lot.

I tried to modify this example for a simple output on pin Y18 on connector JX1 using PL side. I created a knew IP and added an output port in the code:

outPort : out std_logic;

outPort<='1';

After setting the constraint file and automatic connections, I used the Helloword in SDK to run on the zedboard. No error, I followed a complete procedure, but the output pin stays at 0V. Do you have any idea what I'm missing, do I have to had something in Helloword.c?

 

L-P

by Observer taylo_ap
on ‎07-15-2014 01:11 PM

L-P

 

First thing is first are you sure you configured the PL side of the device by generating a new boot image with the updated BIT file ?

 

 

Adam 

by Visitor lphilippe.b
on ‎07-15-2014 01:52 PM

Hi Adam,

Running the IP selftest returns the "Read/Write test pass" meaning the PL is configured with the good BIT file.

I also tried to write on reg0, then output the value on pin Y18, but the result is the same. Right now, I'm trying to see if I can read the pin status.

L-P

by Visitor lphilippe.b
on ‎07-16-2014 11:13 AM

I found my problem, since I don't have a carrier board, Bank 34 and 35 are not powered.

by Adventurer
on ‎12-16-2014 08:12 AM

Adam,

 

The previous blog entry shows the XADC at 0x43c00000 and your peripheral at 0x43c10000 but this blog entry uses 0x43c00000 as the peripheral base address. What am I missing?

 

Also - optional side question - I am running Linux with an image created from 'buildroot' similar to what is loaded on the MicroZed when shipped. After adding XADC as you have done (and getting the same base address of 0x43c00000) the device tree indicates an XADC base adress of 0xf8007100. Just curious if you have done this with Linux O/S and observed a similar difference/mapping.

 

Thanks,

Jason

by Observer taylo_ap
on ‎12-17-2014 11:40 AM

Hi Jason,

 

Sorry the assignement of addresses is done automatically I must have disconnected the XADC and the Core I wrote for this and then remappepd them in as part of the development hence the address change

 

The second part of your question is more interesting and timely if you read my latest blog you will see the reasons for the two addresses on the XADC and how to use the different addresses in a bare metal system atleast 

 

Adam 

by Newbie sryan
on ‎02-25-2015 07:21 AM

I'm having trouble getting the BSP to see the new peripheral. In "system.hdf" I can see the memory address range that has been assigned for "Adams_Peripheral_0", but in "system.mss" it doesn't show up. There is also no listing for it in "xparameters.h". 

 

I tried right clicking the BSP and clicking "Re-generate BSP from Sources". I also tried cleaning and rebuilding the project from scratch. But "Adams_Peripheral" still doesn't show up in "xparameters.h" or in "system.mss". Any idea what I should try?

by Observer taylo_ap
on ‎03-02-2015 03:11 PM

sryan

 

have you ensured you rebuilt and reexported the hardware correctly from vivado to SDK it has caught me out a few times 

 

Adam

by Newbie sryan
on ‎03-03-2015 06:52 AM

Hi Adam,

 

Thanks for getting back to me. I tried exporting the hardware again but had the same problem.

 

What eventually fixed it was deleting the BSP and creating a new one. I then right clicked on the FSB and uzed_app projects and set them to use the new BSP. After that my peripheral showed up. I forgot to mention that I am using Vivado 2014.4 so this may only apply to that version.

 

Sam

by Observer taylo_ap
on ‎03-04-2015 11:04 AM

Hi Sam 

 

Glad you got your issue addressed and thanks for reading the blogs

 

Adam

Labels
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.