Adam Taylor玩转MicroZed系列第88部分： SDSoC之四：探究SDSoC实现出色性能的秘密

By Adam Taylor

Having now demonstrated that we can achieve excellent performance improvements with the Xilinx SDSoC development environment with just the simple click of a mouse, I would like to look a little deeper into how SDSoC performs this trick.

SDSoC accelerates functions within the PL (programmable logic) side of the Zynq SoC using something called the “connectivity framework,” which describes the logical and physical connections between the PL and PS (processor system) sides of the device. Unsurprisingly, SDSoC includes an API to allow transfers using this framework.

Of course the first question that should spring to mind is, “How does the tool know what logical and physical connections are available?” After all, it varies from one system implementation to the next. SDSoC achieves this feat by using two platform definitions: one defines the hardware and the other the software. Within the hardware platform, we will find the definition of the base platform as created in Vivado. So we will see:

• Clocks – All clocks used within the SDSoC platform must be from the processor clocks
• Resets – The number of resets available
• Interrupts - The number of interrupts available
• AXI – The number of AXI and AXI-Streaming connections available

The hardware description can be generated using Vivado and SDSoC.

The software descriptions provide SDSoC with information on:

• Boot Files depending upon the Operating System
• Library packages
• Prebuilt hardware definitions – this saves on compile time.

What this means is that we can still develop a base platform using Vivado—if desired—using custom peripherals and then export the platform to SDSoC, allowing SDSoC to use the uncommitted AXI ports, etc. to produce a higher performing system. So SDSoC increase the performance of pre-existing designs, if you so desire. That’s pretty powerful.

SDSoC implements its connectivity framework with the above information and configuration.

So how does it work?

When you select a function to accelerate a function as we did previously with the mmult() function, SDSoC will:

1. Employ Vivado HLS to generate logic for the PL side of the Zynq SoC
2. Analyze communications to and from the function
3. Establish an AXI communication network based upon the above analysis
4. Generate a software stub function for the function being accelerated

It is this stub function that is actually called in place of the accelerated function. While the software interfaces to the stub function remain identical, its functionality is quite different. The stub function uses the connectivity framework to initialize and send/receive data to and from the PL hardware where the accelerated function now resides.

How the connectivity framework works is really exciting. It uses implementation-independent software API calls to synchronize data transfers to and from the PL. When the code is built, these calls are then translated to the correct drivers based upon the configuration of the AXI network created.

Over the next few weeks we will look at how we can optimize performance even more, now that we understand a little more about how SDSoC works.

Now, you can have convenient, low-cost Kindle access to the first year of Adam Taylor’s MicroZed Chronicles for a mere $7.50. Click here.