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 Five: Adam Taylor’s MicroZed Chronicles Part 25

by Xilinx Employee ‎03-24-2014 01:01 PM - edited ‎04-24-2015 01:21 PM (43,256 Views)

In our last look at the Zynq SoC’s PS/PL interface, I created a very simple peripheral using a DSP48E1 DSP slice to perform multiplication, addition or subtraction depending on a control word in the peripheral’s first register. Suppose that we want to perform a more complex calculation within the Zynq, perhaps for an industrial control system. Typically these systems will have a number of analog inputs (via ADC’s), driven by sensors such as thermistors, thermocouples, pressure transducers, platinum resistance thermometers (PRTs) and so on.

 

Many times, data from these sensors require a transfer function to convert the raw data value from the ADC into one that can be used in further processing. A good example of this is with the Zynq XADC which contains a number of functions / macros within XADCPS.h to convert the raw XADC values into voltage or temperature. However, these conversions are pretty simple. The more complex they become, the more Zynq processing time is required. Calculation can be speeded up considerably if the programmable logic (PL) side of the Zynq SoC is used to perform these calculations. As a side benefit, the processor is also freed up to carry on with other software tasks so you get a significant improvement in processing bandwidth by using the PL for calculations.

 

The more complex a transfer function, the more processor time required to calculate the result. We can demonstrate this impact using the example of converting atmospheric pressure measured in millibars to an altitude in meters (see my article in Xcell Journal Issue 80 – “The Basics of FPGA Mathematics”). The transfer function below gives the altitude in meters for a pressure between 0 and 10 millibars:

 

Figure 1.jpg

 

Implementing this transfer function using the Zynq SoC’s processing system (PS) Zynq is very simple using the following line of code below, where “result” is a floating-point number; a, b, and c are the constants defined in the transfer function above; and i is the input value:

 

result = ((float)a*(i*i)) + ((float)b*(i)) + (float)c;

 

For this example I shall use the above code nested within a “for” loop to simulate steps in the input value. The code outputs the result over the STDOUT. Because I want to calculate the time it takes to perform this calculation, I’ll use the private timer to determine this time, starting and stopping the timer before and after as below:

 

for(i=0.0; i<10.0; i = i +0.1 ){

       XScuTimer_LoadTimer(&Timer, TIMER_LOAD_VALUE);

       timer_start = XScuTimer_GetCounterValue(&Timer);

       XScuTimer_Start(&Timer);

       result = ((float)a*(i*i)) + ((float)b*(i)) + (float)c;

       XScuTimer_Stop(&Timer);

       timer_value = XScuTimer_GetCounterValue(&Timer);

      printf("%f,%f,%lu,%lu, \n\r",i,result,timer_start, timer_value);

     }

 

While this code may not provide the most accurate timing reference, it’s sufficient to demonstrate the principal we will be investigating over the next few blogs. Running the above code on the Zynq-based MicroZed board, I obtained the results below in the terminal window. Note: I extracted this output into Microsoft Excel as a comma separated variable (CSV) file due to the way I had formatted the output over STDOUT:

 

Figure 2.jpg 

 

Performing some simple analysis on this output shows that on average it takes 25 CPU_3x2x clock cycles to calculate the result. That’s not bad. With a 666MHz processor clock, this computation takes 76 nsec. I am sure many people will see that an ADC output will not be floating-point number; it’s a fixed point number. Re-writing the function code using integer math resulted in a very similar average number of clock cycles. However I thought for this example, floating-point numbers would be easier to work with and avoids the need to explain the principals behind fixed-point number systems.

 

Having established a benchmark for how long it takes the Zynq’s PS side to perform a medium-complexity transfer function, we can look next time at just how fast we can compute this same function when we offload it to the PL side of the device.

 

Please see the previous entries in this MicroZed series by Adam Taylor:

 

The Zynq PS/PL, Part Four: Adam Taylor’s MicroZed Chronicles Part 24

 

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

 

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 Explorer
on ‎03-27-2015 05:11 AM

Hello and thank you very much for your blog. It's just awesome.

 

I just have one doubt about the 76 nsec computation time. If if takes of average 25 clocks and the frequency is of 666MHz, dividing 25 by 6.66E8 is 38 nsec and not 76.

 

Am I missing something basic? If so sorry because I'm a complete noob

by Observer taylo_ap
on ‎03-28-2015 09:09 AM

jmales

 

It is 76 ns as the clock which drives the private timer is the CPU_3x2x which is at half the master clock frequency as such a 666 MHZ master clock or CPU_6x4x as it called in Zynq terminoolgy. 

 

As such the rate the private timer is clocked at is 333MHz hence the 76 ns. 

 

Best Regards

 

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.