feature article
Subscribe Now

A Platform to Bridge a Gap?

One of the fun games in marketing is inventing new names: not just product names, but also names for new categories of devices. Some names, in both classes, are good, others are just dire. Field Programmable Gate Arrays was a great coinage. Gate arrays, sometimes called uncommitted logic arrays (ULAs), are regular structures of logic gates that are customised to create a specific design by adding a final metal layer of interconnect but are manufactured on a whole wafer within the silicon manufacturers own plant. Until the first FPGAs were introduced, gate arrays were the only way to create (relatively) dense logic, (relatively) quickly for a (relatively) low price. For small amounts of glue logic, designers would use either a small gate array or a collection of simple programmable logic devices (PLDs). Bigger PLDs are often described as Complex Programmable Logic Devices (CPLDs), and initially the description was applied by some analysts to include the first FPGAs. As well as not describing accurately these devices, the word complex may be thought to possess undesirable negative connotations.

Field Programmable Gate Array, one might argue, could be a little misleading as a name, as few FPGAs are ever programmed after being deployed in the field, but at the time it did provide a neat summary of what the devices were, bringing together in one package the advantages of moving programmability, even re-programmability, from the factory to the system implementer and giving the (relative) freedom of designing devices using gate arrays.

Starting as totally programmable devices representing a mere handful of logic gates, we now have many millions of gates available. Frequently, areas within the FPGA are hardwired by the manufacturer to provide blocks of on-chip memory, support for interface protocols and SerDes processing, and other common functions. FPGA vendors and third parties offer IP to cover a vast array of functions, so the designer doesn’t have to create everything from scratch. And process development means that FPGAs are big enough to allow the IP to include MCU cores, either hard wired or as IP that can implemented wherever in the FPGA the designer needs it.

FPGAs in this context are very much seen as a hardware engineer’s domain, with the softies allowed in to play at some late stage. Even the sequence of start-up – first the FPGA, then the processor – reflects this priority.

Now Xilinx is trying to turn the FPGA world on its head by making the processor the centre of the device with the programmable fabric an extra, almost an optional extra. And this, argues Xilinx, now puts the software engineer first with the hardies following behind. Even the start-up sequence favours the processor, with an operating system booting immediately on start-up, so applications can be running even before the programmable area has configured. While this processor-centric approach is perhaps not quite as important to science as the Copernican heliocentric astronomical model, it still has considerable potential for changing the way in which embedded designs can be implemented. The argument is two-fold. Firstly, most system designs are dominated by the software. Secondly, there are many more people who can write C than can handle RTL.

The new product family is called the Extensible Processing Platform (EPP), with a processor block at its heart. Here Xilinx has gone for the biggie: the ARM Cortex family has become the natural choice for a processor for many developments, including FPGAs, and the Cortex-M0 and Cortex-M3 cores are in use in FPGAs. Xilinx has chosen the top-of-the-range Cortex-A9MP. Even as a single core, this is the most powerful ARM Cortex. But the Cortex-A9 is designed for multicore use and really begins to fly in two- and four-core implementations. For the initial application, Xilinx has chosen a dual-core approach and will also include the NEON 128 bit SIMD (Single Instruction, Multiple Data) engine for accelerating multimedia applications. Packaged in the processor unit will be memory interfaces and common peripherals.

So far, this could be the description of almost any commercial ARM-based microprocessor, but instead of talking through pins to the outside world, the processor talks to a programmable fabric through anything up to 2,500 signal wires. These can be used by almost any protocol, but perhaps the most important is the ARM AMBA-AXI protocol, designed specifically for connecting elements within an SoC with high throughput and low power consumption.

The programmable logic is available for adding more peripherals, either off-the-shelf IP or a custom design, and for implementing additional processing functions. Again, these can be either off-the-shelf or custom designed and, when in use, may be programmed from the processor. This makes it possible, at least in theory, for the processor to re-configure logic to match the immediate needs of the application.

As with all FPGAs, within the programmable fabric, parallelism can be used to massively improve processing of specific tasks. The whole set-up will be fabricated in a TSMC 28nm process.

The approach of using both a processor and programmable fabric allows design to start at high level and the system to be implemented as software. Elements of the design can be carried out using LabView, MatLab, or other tools. Since both Xilinx and ARM have massive ecosystems, there is a lot of available hardware and software IP and tools that can be used to speed up time-to-market as well as reducing risk. Both companies’ products are supported by strong tool chains, and Xilinx says that there is work on closer integration between the two tool chains.

System design can start in software, well before any work on silicon design and even before availability of target silicon. Once a system is running within the processor, the developers can analyse the execution and look at the trade-offs made possible by the ease with which it is possible to implement software in hardware. New C-to-FPGA tools are planned, which should make this even easier. Depending on the importance of execution speeds and overall system performance, this process can be re-iterated multiple times to optimise the design.

A wide range of operating systems has been ported to the ARM Cortex architectures: Xilinx will initially be supporting Linux, but others will follow quickly.

There are several Alpha customers, and two applications that are in development are designs for use in automotive systems and for video surveillance systems. The automotive application gathers information from a range of sensors to combine in one device such safety applications as lane-following (the car warns you if you start to cross the lane markings in the road), distance keeping (this time the car warns you if you are getting too close to the vehicle in front, and can, in combination with active cruise control, keep you an optimal distance from that vehicle), blind spot checking, automatic parking, enhanced vision, and other applications.

The video application puts processing into surveillance cameras. With multiple screens, control room operators can often miss important information. By pre-processing the signal before transmitting it, the camera itself can alert the operators to potential issues.

Xilinx is currently only outlining the idea of an EPP. If you want to sign an NDA, you can have the architectural information today, but the details will not be publicly available until early 2011. The first samples will be shipped “in 2011”.

The number of FPGA starts has been growing steadily, but not spectacularly. Xilinx hopes that using the EPP will provide a step up in the number of starts, by involving software guys in designing systems. However, they may still be some way off the magic C-to-FPGA tool: particularly when this involves parallelism, it may be a tough nut to crack. (Anyone remember Handel C?) This is not the first time that there has been an announcement of an approach that will provide more involvement for the software side in developing FPGAs. Unlike some of the earlier announcements, this isn’t declaring the death of the hardware engineer: there will still be more work than there are people to do it. However, this approach has been thought through and looks like it provides a way to combine both hardware and software skills that will make it practicable to get the next generations of large systems into the field in a reasonable time scale and at a reasonable cost.

I am not certain that Xilinx has cracked the naming problem though. Extensible Processing Platform doesn’t really have a zing to it, does it? Platform is one of those words that, as Humpty Dumpty said to Alice ‘means just what I choose it to mean…’ Xilinx has already been using Targeted Design Platforms to describe the different members of their Virtex-6 family, so perhaps Platform was hanging out in the halls of the marketing department looking for another job? 

Leave a Reply

featured blogs
Nov 15, 2024
Explore the benefits of Delta DFU (device firmware update), its impact on firmware update efficiency, and results from real ota updates in IoT devices....
Nov 13, 2024
Implementing the classic 'hand coming out of bowl' when you can see there's no one under the table is very tempting'¦...

featured video

Introducing FPGAi – Innovations Unlocked by AI-enabled FPGAs

Sponsored by Intel

Altera Innovators Day presentation by Ilya Ganusov showing the advantages of FPGAs for implementing AI-based Systems. See additional videos on AI and other Altera Innovators Day in Altera’s YouTube channel playlists.

Learn more about FPGAs for Artificial Intelligence here

featured paper

Quantized Neural Networks for FPGA Inference

Sponsored by Intel

Implementing a low precision network in FPGA hardware for efficient inferencing provides numerous advantages when it comes to meeting demanding specifications. The increased flexibility allows optimization of throughput, overall power consumption, resource usage, device size, TOPs/watt, and deterministic latency. These are important benefits where scaling and efficiency are inherent requirements of the application.

Click to read more

featured chalk talk

STM32 Security for IoT
Today’s modern embedded systems face a range of security risks that can stem from a variety of different sources including insecure communication protocols, hardware vulnerabilities, and physical tampering. In this episode of Chalk Talk, Amelia Dalton and Thierry Crespo from STMicroelectronics explore the biggest security challenges facing embedded designers today, the benefits of the STM32 Trust platform, and why the STM32Trust TEE Secure Manager is an IoT security game changer.
Aug 20, 2024
39,807 views