FPGAs for the Masses?

by Dick Selwood, May. 10, 2016 – 

Over the years, there have been many attempts to make FPGAs easier to use, and most of them now occupy the footnotes of FPGA history. So when I got a note from Stephane Monboisset introducing me to a new FPGA design tool called QuickPlay from a company called PLDA, I was about to send a polite, "Thanks, but no thanks," when I remembered where I had last met Stephane. It was when Xilinx was launching Zynq, and he was very successfully handling the European aspects of the launch, including the press conversations. The fact that he had moved from Xilinx to PLDA made me take it more seriously.

The context in which QuickPlay has been developed is that, while FPGAs can offer a great way of developing products and can often provide performance and other advantages over using, say, multicore processors and GPUs, they are now complex beasts. They need experienced hardware engineers to implement the intricate designs that provide the performance advantages, and projects can take a long time from initial concept to a debugged device that is ready for delivery. QuickPlay is intended to open up the development process to software people and improve the speed and quality of implementation.

It was, for me, a little difficult to get a grasp on exactly what QuickPlay is. Let's start with what it is not. It is not a complete tool chain for FPGAs - it relies on the synthesis and place and route tools from the device manufacturer. It is not an all-purpose tool; it presumes that you will be developing a system based on one of a (wide) range of boards. But it is a way of developing systems around an FPGA that is accessible to people who are not hardware experts.

Stepping back a bit, QuickPlay already has in place an ecosystem - the QuickAlliance programme - with partners who supply pre-validated IP cores and libraries in VHDL, Verilog, and C, a group of board partners and partners who provide tools that integrate into the QuickPlay design flow, and suppliers of design services.

The underlying model of the QuickPlay approach is based on how a software developer thinks - that a design is a number of functions that communicate with one another and also with the outside world. For the hardware implementation, these designs are considered kernels.

The design flow is to create a software-functional model, using C or C++ implementations of the kernels from the IP library or building them from scratch, and verifying the model using standard tools and methodologies. Once the model is clean, then a hardware engine is generated for an FPGA platform along with standard I/O.

Now clearly there is a great deal more going on under the hood. Let's go back to look at the flow in a little more detail. The QuickPlay, Eclipse-based IDE has a working space for drag and drop from libraries of functions in C or C++ or even HDL. These can be from PLDA or from the ecosystem, or they can be developed in-house. Streaming communications channels link the functions, and these can include links to memory blocks and system I/O. Parallelism is supported by merely duplicating functions.

When the system model is assembled, it can be compiled and then exercised with a test program to verify behaviour. For example, is the output from the system appropriate for the input? The IDE includes open source debugging and other tools.

Once the software model is performing according to specification, then it is mapped onto an appropriate target board with an FPGA and physical interfaces. The FPGA is implemented using the manufacturer's tools within the IDE. The board can then be exercised with a wide range of tests, in parallel with the software model. As QuickPlay has guaranteed functional equivalence between the software model and the hardware implementation, if there are any bugs in the hardware, then they also exist in the software. There is no need for hardware debugging, since fixing the software and re-targeting to the FPGA automatically fixes the hardware.

What are the benefits? We have seen that the developer doesn't need to know what is happening at much below the functions of the kernels. There is no need to worry about clock networks, timing, communication stacks and protocols or a raft of other issues that normally absorb significant energy of the hardware engineer. The implementation is correct by construction, so there is no need for hardware level verification and debugging.

The promise of creating hardware without hardware engineers has been a holy grail for some for many years. Every few years, there is an announcement that this has been achieved, only for the breakthrough to gradually fade away (Handel-C anyone?). With QuickPlay, we may be getting there, even if it is for only a subset of all possible applications. See for yourself in the selection of video demos at https://www.youtube.com/channel/UCM-Loe1CQ6iNgC32ndtWakA

 Back