Field Programmable Gate Arrays (FPGAs) have been in use for decades, enabling high-performance algorithm acceleration through reprogrammable logic blocks. Working with this type of near-infinitely flexible hardware has helped product developers push performance boundaries that their predecessors once saw as irrefutable.
Still, they are bound by some frustrating restrictions.
The unique characteristics of various FPGAs have made it difficult to develop a class of tool that works with without time-consuming reconfiguration. Even the most commonly used components, like FIFOs and UARTs, cannot be reused reliably between two different designs, while the lack of a hardware description language standard has led to a fragmented landscape of development tools required to work with them.
“Open Source Software and Silicon advocate” Olof Kindgren has long rallied against the need to build new UARTs from scratch, further complicating the requirements for a new design. As he puts it, “I use the UART as a pathological example because it’s a function that’s so simple that many people feel it’s easier to write a new rather than reuse an existing one. But in practice this leads to yet another implementation with bugs but without proper docs, tests and drivers.”
The complexities only snowball from there.
Developers must rely on finicky design-specific tool chains when working with FPGAs in order to customize the programmable logic to interface with new or existing systems. These tools are typically built for portability across a single vendor’s devices, and only occasionally account for cross-platform differences between devices of other vendors. One example is Vivado, which uses a synthesizer capable of compiling HDL code for Xilinx‘s mid-scale and large FPGAs and SoC development. A more recently released solution from Xilinx is the Vitis unified software platform, which combines synthesis of common software languages like C++ and Python with low-level programmability making it possible for any developer to simulate FPGA design for AI and machine learning applications, cloud-based applications, the Internet of Things (IoT) and more. Vitis is open source, but it’s also tailored to Xilinx devices.
Venture to another vendor’s devices and design synthesis is once more impeded by the cost of new licenses for a new tool set, and another learning curve to surmount.
Open source tooling can reduce the financial costs of a project, but portability in the form of component and software reuse may have an even greater business impact. The following potential benefits make a compelling case for an open source FPGA development standard, and important tools for the community to consider:
A standardized tool set brings greater confidence to complex product development, knowing a solution will perform as expected in all device families with minimal porting effort required.
When a major aerospace company decided on a radiation-hardened FPGA-based platform from Microchip for a product that would accompany NASA astronauts on missions to the Moon and Mars, DornerWorks engineers guided them to a softcore processor using the open source RISC-V architecture and a modified version of our own MAC IP core. This is helping the company reduce one of biggest barriers space travelers face when trying to communicate with loved ones back home, and gain a stronger hold on their market. It also expanded the RISC-V ecosystem, highlighting the open source hardware architecture’s potential in state-of-the-art applications.
Building components using the RISC-V architecture, to continue the example, ensures that those components will run successfully on any other device that supports RISC-V. Currently, not every device does, hence the impetus for further expansion of that ecosystem.
With a supported standard, there is less risk of components becoming obsolete or breaking when new components are introduced. There are fewer “unknown unknowns” facing development teams as the greater open source community builds on the knowledgebase for those software components and tools. And there is less risk of non-compliant workarounds triggering a time-consuming audit.
A standardized tool set shortens development schedules by enabling greater software and component reuse. Development teams no longer have to rebuild their designs from the ground up when moving to a different vendor’s platform. Moreover, there is less time spent on building workarounds to accommodate different platforms, with little to no loss of performance in the finished product.
If updates need to be made in the future, the company can implement them quickly. Plugging in new functionality will take far less time than building an entirely new ASIC at every milestone. Likewise, when the tool set is familiar, developers know what they are getting into, before they are getting into it.
Collaboration between other teams both inside and outside an organization is made much easier, and much more productive, when everyone is on the same page. Key contributors can change and/or be onboarded quicker when using standardized tools, as there is a reduced need to borrow specialists from elsewhere.
When it comes to products in the field, a company that builds unique software and hardware components for each different platform also multiplies its own responsibility to maintain those components. The greater the catalog of disparate products, the greater the burden placed on engineers who must keep track of legacy systems that will inevitably fall below profitability.
Xilinx and a growing community of developers have been using and advocating for tools like Versal ACAP that can facilitate FPGA configuration in a C code environment. Aligning these tools with a single open standard would make FPGA development more accessible to software developers, as they wouldn’t have to worry about all the low-level differences between vendors.
Reliance on a single tool set and framework eliminates the need to translate code or implement workarounds when interfacing with different devices. It also paves the way to more reliable, and more easily constructed designs. When the company decides to add a new product to its portfolio, the effort may be as simple as calling in a few new lines of code to augment the base framework.
Open source standards and tools can allow easier contributions from outside of the company, such as academic or hobbyist entities. Sometimes these contributions can form the ground work for novel features that are not on the primary roadmap.
For example, the Dept. of Electrical and Systems Engineering at the University of Pennsylvania, used Symbiflow, an open source FPGA tool stack, to demonstrate how parallel compilation with partial reconfiguration can dramatically improve FPGA implementation times. While a similar improvement was shown with proprietary tools, only the open source tools could be leveraged to fully take advantage of this technique.
An FPGA vendor could integrate this feature into their tool but this integration can take several tool releases to be completely optimized. In contrast, once a feature is released upstream for an open source tool, any sufficiently motivated user could leverage the patches to bring the new functionality to their toolchain.
As overhead costs related to proprietary software licenses go down, it stands to reason that a company’s profit margin would concurrently increase. Perhaps more importantly, adopting an open standard can prompt lasting organizational and relational benefits that also impact the bottom line.
Development teams will see their skill sets become more unified when using standardized implementations. This affords the business room to organize engineers on other projects that might otherwise be queued up for weeks longer, respond more quickly to customer issues, and create longer-lasting relationships with those clients.
Open standards have helped companies reduce the barriers to innovation in software development for decades. More recently, the same methodologies have been applied to industry standards by The Open Group Future Airborne Capability Environment (FACE™) and Sensor Open Systems Architecture (SOSA™) consortiums. Safety-critical software and networked sensor systems play an important role in modern aerospace and defense platforms, and as these systems become more complex they can be a challenge to easily integrate with other system components. The FACE Technical Standard and SOSA standards essentially define a playing field for companies to unite on when building solutions for government and commercial organizations. Companies that learn to play on that field, win the contracts first.
Given these potential benefits, the argument for a standardized open source FPGA development tool set deserves more attention. Xilinx has made FPGA development easier for software developers using Versal ACAP. Upstreaming that accessibility to an open standard would enable the same capability to developers with other devices, while extending Xilinx’s reach as a solution provider. Microchip’s PolarFire SoC devices also follow the open source thread into the hardware realm, with a deterministic, coherent RISC-V CPU cluster. Yet while the open source RISC-V framework is enabling efficient and capable solutions for use in space and on earth, it is not yet universally adaptable between vendors.
Thinking of FPGAs simply as hardware belies their flexibility, just as categorizing them as software downplays the potential of parallel processing. As an intersection of both, FPGAs can enable tremendous benefits in the way of lower recurring costs and risk mitigation. An open development standard would not just make working with FPGAs easier, it would lead to more capable teams, and better products.
DornerWorks has years of experience working with FPGAs and open source tools. We can help you remove the development roadblocks involved in FPGA implementation and prototype products that your customers will love. Contact us today to schedule a meeting, and we will map out a plan to grow your business.
DornerWorks Chief Separation Technology Engineer Nathan Studer contributed to this article