Flexible SoC systems, including external "hard" components, can be plugged together using FPGA-based Wishbone bus architecture cares that act as versatile interfacing layers.
By Rob Evans
Indeed, there’s an underlying requirement here for advancing beyond the limitations of a traditional SoC design approach. What’s needed to make the systems outlined in this article viable is a high-level design system that brings all of the design processes into one sphere. By using a single design application that draws from a single data model of the entire design, the divisions between the design domains—embedded software, programmable hardware, and physical hardware—can be broken down.
Most hardware and software engineers are familiar with FPGAs. However, for some, that awareness might not be on a practical level, but rather from a conceptual point of view. The rapid progress in capabilities and spiraling downward cost has been hard to ignore. In addition, there’s the obvious convenience of using this type of programmable device as a flexible and cost-effective container for swathes of digital glue logic.
Simply considering FPGAs as a more cost-effective and versatile choice than taking an ASIC approach ignores the enormous possibilities they offer. To fully harness that potential requires a different mindset toward design. It goes way beyond traditional SoC thinking, and its ASIC heritage.
The conventional development process for an FPGA-based product design reflects traditional thinking by regarding each part of the design (hardware, software, and embedded hardware) as separate, disconnected tasks. This means, just as in an ASIC development scenario, major decisions such as hardware-software partitioning are made (and locked in) early in the design cycle.
The upshot is that physical hardware (FPGA devices and peripheral hardware) and then programmable hardware elements are locked down, in sequence, before meaningful software development can proceed. Those initial decisions define the parameters and constraints for the following development steps.
As a result, the design options become increasingly limited through each sequential stage. Concepts like fine-tuning a design by shifting the software-hardware partition, changing from an embedded to hardwired processor, or opting for a different FPGA device type are just not in the mix.
Any design variation at these fundamental levels will force a substantial redesign in all domains—hardware, programmable hardware, and software. The resulting design cycle disruption is untenable, so we avoid tackling this type of design exploration at all costs. In a nutshell, software is created within the restraints of the programmable hardware, which has in turn been constrained by the properties of the fixed physical hardware.
SMART LAYERS
Applying a conventional SoC design approach to an FPGA platform imposes most of the limitations of an ASIC-based methodology, but the enormous flexibility of FPGAs has more to offer. This is particularly true if the FPGA development process is intimately bound to the hardware and software development processes, where they all share the same design environment and pool of design data.
Consider the liberating possibilities, for example, if flexible interface layers could be introduced into the FPGA fabric that effectively isolate the design’s “soft” elements from the host hardware. The potential would then exist for both the application software and programmable hardware design to be changed with minimal influence on the surrounding hardware systems.
With this approach, FPGAs also take on a peripheral, I/O coprocessor and interface connectivity role. Along with hosting the highlevel functional elements that make up a conventional SoC system, an FPGA also acts as the interfacing fabric for the hard and soft elements of that design. A processor, memory, or DSP might be implemented as a soft core or as physical hardware—or even both—while reprogrammable layers hosted by the FPGA stitch it all together.
These additional FPGA-based elements would typically act as interfaces between processors and hardware such as memory and peripherals. They “normalize” the interface between functional devices, so that designers needn’t deal with the lowlevel hardware complexity of I/O configurations and bus systems. In effect, the layers abstract a peripheral or processor interface, making it easy to change these functional devices without disrupting the surrounding hardware.
In practice, both processors and peripherals are supported by FPGA cores based on the Wishbone bus architecture (see the figure). The core abstracts a processor interface by effectively “wrapping” around the device, making it architecturally equivalent to other processors. Therefore, it’s easy to change the processor without affecting the connected peripherals. Along with FPGA-based “soft” devices, the concept can be extended to include hybrid hard-core processors, external processors, and off-chip discrete peripherals and memory devices.
HIGH-LEVEL DESIGN
After dealing with most of the low-level hardware architecture, there’s the opportunity to introduce high-level FPGA design-capture systems that allow designers to simply connect together functional blocks of logic. Wishbone-compliant components (pulled from a library) can be plugged together on a schematic sheet, or at an even higher level of design abstraction, with simple graphics (representing functions or devices) arranged in a flowchartlike configuration.
This type of high-level approach is made possible by capitalizing on the reprogrammable capability of the FPGA host. Any imposed layers and interfaces can automatically be included in the fabric of the FPGA, along with the functional design itself. Unlike the conventional process applied to fixed SoC product design, the FPGA equivalent allows the hardware design to be dynamically explored without fatally disrupting the other parts of the design.
This approach is also significant from a software developer’s perspective. To write software that accesses or controls a peripheral device, you need, for example, a thorough knowledge of how that device works at an underlying hardware level. Therefore, that means deciding on the optimal device registers, device-specific commands, communication protocols, and interrupts to handle.
To satisfy this need, software drivers and context handlers can be added to the “normalizing” hardware interfacing layers in a stack arrangement. Like the Wishbone wrapper cores, these driver layers are downloaded into the FPGA at build time to handle the low-level hardware interfacing complexity.
Conversely, many hardware developers have sufficient programming knowledge to tackle application software development, but are held back by the knowledge requirements in operating systems, communications stacks, user interface frameworks, and so on. The layers and driver systems again remove these barriers by bridging the gap between hardware and software, allowing all engineers to develop much more sophisticated products, while building on their existing skills.
PROGRAMMABLE UNITY
The flexible technology of FPGAs is also an ideal environment for moving software routines and algorithms into hardware to squeeze the most out of them. C-to-hardware transformations in the FPGA space can be arranged to be a dynamic process, rather than the fixed, preset arrangement of the ASIC SoC alternative.
When the software and FPGA development environments exist in the one sphere, selected software functions can be “duplicated” as equivalent co-processors in FPGA hardware. In turn, the alternative options can be enabled to judge the performance improvement.
Along with the obvious advantage of moving functions like parallel processing into the soft realm, it’s also possible to exploit the inherently programmable nature of an FPGA’s physical device pins. This will reduce board-routing complexity and simplify external connectivity.
For example, in a typical situation where the most practical placement of physical hardware components creates extremely complex FPGA-toperipheral connectivity, in part due to high-density BGA packaging, key paths can be made via the FPGA itself. Here, the FPGA’s pin reassignment and internal routing capabilities are employed to solve a board-routing challenge, potentially reducing the board area as well as the number of layer requirements.
This concept, again, relies on the existence of a hardware-software- FPGA development environment that’s connected at the platform level. It’s needed in order to support intelligent and automated pin-swapping between the hardware-FPGA domains.
Indeed, there’s an underlying requirement here for advancing beyond the limitations of a traditional SoC design approach. What’s needed to make the systems outlined in this article viable is a high-level design system that brings all of the design processes into one sphere. By using a single design application that draws from a single data model of the entire design, the divisions between the design domains—embedded software, programmable hardware, and physical hardware—can be broken down.