The Kitchen Zynq
For the last few weeks I've been working with the Zedboard a development board that sports a Xilinx Zynq...well... it doesn't seem fair to call it a CPU. As I mentioned before, it is a dual ARM CPU integrated with FPGA fabric so you can add custom FPGA designs to the CPU.
Overall, I've been pretty pleased with the Zynq. It would have been fairly easy to make something this powerful basically unusable, but Xilinx has done a nice job of delivering an integrated solution. I'm not sure everyone will use the full potential of the device, but the toolchain allows you to get started relatively easily and build up to more powerful designs with time.
For example, if you simply put a CPU and an FPGA together on a board, there's no doubt there are interesting things you can do — many designs are exactly like that. However, you have to figure out how to talk between the CPU and the FPGA. That can be simple, of course, unless you are worried about getting the most bandwidth available between the two devices.
With the Zynq, the toolchain knows how to incorporate standard interconnects like AXI. If you want the maximum performance, you'll need to choose that interconnect wisely. The AXI HP bus, for example, directly accesses memory (bypassing the cache). The AXI ACP (Advanced Coherency Port) port works with the cache for better writing speeds. The ports can run at 150MHz even in the lowest speed grade device.
There are two 32-bit AXI ports in each direction (that is, the CPU has two masters and the FPGA has two masters). There are also four AXI ports that can access memory (these can be configured for 32-bit or 64-bit operation). In addition there is a single AXI ACP port. The FPGA can signal the CPU with 16 different interrupts.
The other complexity issue is access to all the FPGA resources. There's a significant IP catalog built into the Xilinx Vivado tool that includes access to the busses, among other things. If you drop them on the design's block diagram, you'll often get an offer to use "connection automation" to wire everything together.
That's only part of the problem though. If you add a timer or some I/O, you still need to get to it from your software. If you had to write a custom board support package (BSP) for every new design (and update it for every change) you'd lose a lot of advantage, especially for smaller projects.
When you are ready, you can ask Vivado to export your project to the Xilinx SDK (see the Figure below). As part of that operation, you get a board support package to work with your devices. You even get documentation for the BSP, although on my Linux box, the SDK won't directly open a web page. I can still navigate to the page on my disk in a browser, though (and, yes, I've set the Web Browser setting in the Preferences dialog).
The BSP, of course, is just a collection of canned code for the provided IP that gets customized to match what you did with the IP. For example, here's a very simple example of setting up an input port (with no error checking):
static XGpio GPIOInstance_Ptr; u32 Readstatus; XGpioPs_Config*GpioConfigPtr; XGpio_Initialize(&GPIOInstance_Ptr,XPAR_AXI_GPIO_0_DEVICE_ID); XGpio_SetDataDirection(&GPIOInstance_Ptr, 1,1); Readstatus = XGpio_DiscreteRead(&GPIOInstance_Ptr, 1);
Here's part of the documentation provided for XGpio (in particular, the
The Zynq is a pretty powerful chip, but the tools do a nice job of letting you build a working system without a lot of effort. I'll have some more on Zynq in the future (but not next time). Meanwhile, if you want to work through a tutorial, there are several on the zedboard.org site. Even some of the older ones that target the ISE suite have some useful concepts.