TECHNOLOGY IN SYSTEMS
Meeting the Challenge of Developing with FPGAs
Portable and Reusable FPGA Frameworks Let Engineers to do what They do Best - Design
Reusing design elements should not require the redesign of those elements themselves. The use of a framework with well defined layers of abstraction and interfaces can go a long way toward relieving the need to reinvent the wheel.
JEFFRY MILROD AND KRISTEN ZAFFINI, BITTWARE
Page 1 of 1
The definition of a design engineer, per Wikipedia, is one who “works with a team of engineers and designers to develop the preliminary design and the most critical parts.” In today’s FPGA-centric world, for most design engineers the development of “critical parts” is becoming an ever shrinking piece of their total effort. One major reason for this is that it is often difficult or impossible to reuse previously developed critical parts, requiring that they be redeveloped and revalidated with every new generation or feature. Moving to the next generation of an FPGA project, or updating an existing project typically requires rewriting interfaces, modifying timing constraints, reintegration and rebuilding of simulations of existing critical parts—the dreaded reinventing of the wheel.
This work of reinventing the wheel can add up to days, weeks, or months with little or no time left for adding real value with the creation of new critical parts. If only we could hop in a time machine and go back to the days when design engineers spent the majority of their time developing the systems of the future rather than rebuilding and tweaking the systems of the past.
What if tomorrow’s FPGA design could be built better and quicker, with time left over to add in features that wouldn’t even have been attempted if the design engineers had to spend their time writing yet another variant of their UART? When building the next FPGA project, the key to harnessing tomorrow’s cutting-edge technology today is to use a COTS FPGA framework that provides portable, reconfigurable and reusable FPGA components. A COTS FPGA framework can be like the iconic DeLorean DMC-12 from the movie, speeding up the design process to 88 mph so that the design engineer is transported back in time to find that the FPGA is already stocked with a fully validated project including data planes, control planes and physical interfaces for all board-level I/O communications and external memory.
In addition to a wealth of proven, validated components that can be quickly dropped in to a project, a COTS FPGA framework can have several other attributes that facilitate FPGA design portability and reuse. Hierarchical layers of abstractions support rapid changes of hardware at the board and/or FPGA level. Common interfaces create a building block approach to connecting components, thus enabling quick and easy component additions or replacements. Parameterized component reconfiguration allows designers to easily modify a given component without having to reintegrate or rebuild simulations. Finally, dynamic reconfiguration allows control software to modify the operation of FPGA components without needing to recode them.
Hierarchical Layers of Abstraction
Hardware flexibility is accomplished by using abstraction levels. As shown in Figure 1, each abstraction level can be thought of as a puzzle piece, with the ability to remove and replace each puzzle piece with another abstraction level.
The board level is the lowest level of abstraction and is responsible for the interface between the FPGA physical signal interfaces (i.e. pins) and the ports on the FPGA device. The tool’s board-level definition file only needs to be created once per FPGA/board pair and can be shared across all projects that use that product; a COTS framework would provide this level for a supported board. The physical level contains all the physical interface components required to provide project support, converting data and control between the board level and user level. Finally, the user level contains the “meat” of the project such as the processing. This is where the real value-added of the project resides, and where the designers should be spending their time.
The designer is able to quickly move the project user level between boards and/or FPGAs by simply swapping out one board-level definition file with another that contains the resources that a given physical level is using. From the perspective of the user level, it does not matter where it is getting its control or data from, nor where it is sending the processed data and status, so long as its input and outputs communicate using the common interfaces. As a result, it is possible to port the user level to different physical levels and thus, to different boards or FPGAs in a seamless manner.
Virtually every FPGA component requires some combination of: data in, data out and a control plane interface. By standardizing these interfaces—memory mapped for addressable transactions like control and status, and streaming for high-speed point to point transfers—components can be modular and interchangeable. One such standard is Altera’s Avalon Streaming and Avalon Memory-mapped interfaces, which are used by BittWare’s Atlantis FrameWork, as shown in Figure 2.
Consider a design that uses an existing high-speed serial fabric endpoint between a SerDes physical interface and an internal DMA controller, but the new system spec requires a different fabric protocol. The framework greatly simplifies changing the protocol. Without a common interface, the design engineer would have to build adapters, gaskets, and interface translators each time they connected two different components together, then begin reintegration and validation. Using a common interface allows the developer to pull out one endpoint, drop the new one in and simply connect it back up to the existing SerDes PHY and DMA controller. Connecting the new endpoint’s standard memory-mapped registers to the control plane will then open up the dynamic reconfiguration options discussed later.
Parameterized Component Reconfiguration
Using high-level language parameterizations, the specific configuration of a given framework component can be readily changed. Changing these parameters can reconfigure the component’s functionality, data widths, numbers of ports, speed, size, formats, etc. Scripts with included timing constraints can then be used to synthesize and simulate the reconfigured component. Since it is still basically the same component with the same interfaces but with just a different configuration, it is easily integrated into the project and project-level simulations.
As an example of how powerful this can be, imagine a design that uses a data switch that has more ports than are required in a new project. The well designed framework component allows changing the number of ports by simply changing the component’s parameters. Using the parameterized component reconfiguration provided, the developer avoids having to waste resources for unused switch ports or having to write a new switch with fewer ports. Similarly, if a DMA controller was expecting 64-bit streaming data input while a new data receiver would be pumping out 128 bits, the developer could simply change the data width parameter on the DMA input receiver to 128.
Dynamic Reconfiguration: Cut Down on Testing and Validation Time
Dynamic reconfiguration allows the developer to make changes to a component without having to change parameters and resynthesize via the components control registers; these are “on-the-fly,” or dynamic, types of changes. Even if a component supported dynamic reconfiguration, without a framework with a standard control plane and supporting drivers and software, it would be the developer’s responsibility to create an interface to control these dynamic reconfiguration settings. Some examples of changes that could be dyamically reconfigured are base addresses, DMA pointers and mux settings.
A more complex application of dynamic reconfiguration could be applied to the new fabric endpoint discussed previously. Altera’s FPGAs, such as the Stratix family, have SerDes transceiver configuration settings that can be reconfigured dynamically. These settings include voltage output differential (VOD), pre-emphasis, equalizer control and equalizer gain. Since these are each an on-the-fly change, all that is required is writing to the reconfig register via the framework. So if during real-world system testing it is discovered that a given serdes fatpipe isn’t as clean as was expected and the bit error rate is higher than the spec allows, rather than spending weeks or months optimizing the analog controls, it can be dynamically reconfigured in milliseconds and reevaluated. Note that a more fundamental change, such as SerDes speed, might not be dynamically reconfigurable via run-time software but could be changed “statically” via parameterized component reconfiguration and resynthesis.
The nature of most designs is evolutionary—adding value to existing designs via optimizations and new features. Hardware designers and software designers have gotten quite proficient at reuse of existing design elements to support this evolutionary style of development. Complex FPGA project-level design is a much younger discipline, and is still playing catch-up with hardware and software regarding design reuse. Depending on the project, FPGA designers can spend more time reinventing wheels than actually developing real value-added and critical parts; it’s probably a toss-up as to whether that frustrates the project managers or designers more.
FPGA Frameworks, such as BittWare’s Atlantis FrameWork (AFW), facilitate FPGA design reuse and portability by providing hierarchical layers of abstraction with components featuring common interfaces and reconfigurable capabilities, leading to more efficient development, less design maintenance, and more opportunity for inventing new critical parts. Using such tools, designers can go back to the days when their energy was focused on creating the systems of the future, rather than having to constantly hack up projects from the past. Start revving up the DeLorean, we’re going… Back to the Future.