Division between hardware and software in product design and development enables greater flexibility and functionality.
By Rob Evans
It doesn’t take too much analysis of today’s electronic products to notice that the competitive value in the majority of those designs lies in the software-defined elements that characterize the product’s function and user experience. Since the birth and widespread adoption of microprocessors, the trend toward software-centric design has continued at a rapid pace to where a product’s physical hardware takes a supportive back-seat role. It acts as a host and external interface for the software that defines a product, rather than determining the aspects of that product in its own right.
The development of a product’s physical hardware, while still important, has become part of the design process that adds little sustainable differentiation to the final result. An indication of this hardware design trend can be seen in the ubiquitous contents of today’s circuit boards, which generally contain processors, interface peripherals, and supporting glue logic–and in an ever-increasing number of programmable devices, such as field-programmable gate arrays (FPGAs).
The majority of those hardware devices and blocks of circuitry have become commodity items that are available to everyone, and do not deliver any properties to the overall design. One keypad interface or USB port is pretty much like any other, so there’s no point in designing from scratch to reinvent physical hardware that is easy for others to copy.
Where the value of design lies, and where the prime focus of design effort should lie, is in the soft elements of a design that define its competitive advantage. Today, this is a product’s true IP–its “device intelligence.” However, in conventional design flows the initial part of the design cycle is directed toward creating the physical hardware platform to support those software elements. Meaningful software development can’t proceed until a hardware prototype is available, so several key device hardware decisions must be made first, and then a suitable platform designed and created.
Unfortunately though, just how suitable that hardware really is can become somewhat of a lottery, because the “soft” elements it must support are yet to be developed. As that software development progresses, the required capabilities of the hardware platform will become clearer, yet its configuration has already been locked when the initial prototype was created.
It may become obvious, for example, that the design will benefit from–or only be achievable with–a different type of microprocessor or programmable device. The options are to create a revised hardware prototype–and possibly a series of them–to achieve the intended product performance and behavior, or compromise the final result by sticking to that hardware. The reality is that the core design functionality is being held back by the predetermined hardware platform, and changing it would cause a significant delay in the product development time.
Putting hardware in its place
In many ways, this product development approach is backwards. Conventional design flows, and in particular those based on embedded design tools from FPGA vendors, reinforce the problem by dictating a sequential and limited approach to design. The overall process is based on a collection of separate and isolated design tools. Each completed task must be handed over to the next then reinterpreted in that domain, and the choice of physical hardware devices is limited by the partisan nature of the vendor tools.
Perhaps the main barrier to a soft-centric approach to product design, in a nutshell, is that current tools and design flows lock the development of software and physical hardware together. What’s needed is a way to isolate the defining IP of the design–the device intelligence that determines its functionality and competitive value–from the hardware platform and devices that support it.
This requires the use of a design system that raises the level of abstraction of the design processes so that the design IP is not tied to particular physical hardware devices, microprocessors, or even proprietary IP cores. Such a system would allow designers to focus first and foremost on creating a product’s core design intelligence.
High-level design tools
The starting point for a design system that frees designers to create a product’s key functionality is one that is independent of FPGA vendor or device. Unlike conventional IDE toolsets from device vendors, a “neutral” embedded development system allows designers to both choose and change the programmable device to suit the software under development, rather than the other way around.
Such a system can achieve this capability by providing matching driver files and hardware libraries for each supported programmable device. The drivers can automatically supply the design system with full knowledge of the target architecture such as programming information, pin-out capabilities, and boundary scan data, while the library files provide the physical and graphical models for the device. The system can also be supported by a hardware development board with plug-in device boards, allowing the entire design system to simply align itself to the current choice of programmable device.
In a conventional design flow, however, changing to a different FPGA requires significant re-engineering to suit the programmable device. This is because the design-to-device targeting information that needs to change–timing requirements, place and route data, and port to pin mapping–is generally contained within the source design files. However, if that linking information is stored in separate design constraint files, the design is configured to the target FPGA in a more flexible way. A constraint file will target the design to a different FPGA, allowing the design source to remain largely unchanged and independent of the device on which it is implemented.
An approach to multi-device compatibility can also extend to library collections of embedded IP. If the function blocks and components in the IP libraries are pre-synthesized and verified to suit the architecture of all supported devices, the embedded design can be easily developed from ready-to-go blocks of circuitry without having to worry about the underlying device architecture. Along with core blocks of functional logic, this soft IP would include microprocessors, peripherals and memory, so everything you need is ready to go, regardless of the hardware platform.
Another level of unlocking the soft elements of a design from the hardware that supports it is implementing design abstraction layers into the embedded hardware design itself. Library components with the Wishbone OpenBUS standard can be included to normalize the interfaces between processors, memory, and peripherals to simplify and speed up the design process. What’s more, library-based hardware interface cores can be introduced to “wrap” around pre-
defined processors and peripherals, providing an isolating layer between the existing interface arrangement and a hardware Wishbone bus. The low-level hardware interface complexity is then handled by the system rather than the designer.
These configurable hardware interface cores allow third-party or vendor IP blocks (and even discrete hardware processors) to be dropped into a design easily and changed at will. Changing to a different processor IP block causes minimal influence to the surrounding hardware, and when backed by compiler tool chains for all supported processors, the embedded software can remain intact. Again, the core design intelligence is not intimately bound to the physical and embedded hardware, which reduces complexity and allows hardware decisions to be made much later in the design cycle.
Simplifying the embedded hardware structure and design processes in this way means that complex processor-based embedded systems can be created and changed easily. The division between hardware and software is more flexible, allowing the partition to be moved throughout the design cycle rather than be locked at the beginning of the embedded development process. It also opens the possibility of implementing high-level systems that translate software algorithms into hardware co-processors, so the options can be compared and selected accordingly. Again, the low-level hardware complexity is removed from the design decisions and processes, allowing the designer to focus on creating a product’s functionality.
Capturing innovation
With high-level abstracted interface systems in place, the opportunity then exists to raise the abstraction level of the embedded design capture system itself. This is possible because the complexity of the hardware architecture has been hidden, core hardware and device components can be changed without forcing a redesign, and most importantly the software-based functionality of the design has been unlocked from the hardware platform. Because the low-level design considerations are taken care of by the design system itself, the focus can be redirected towards developing a design’s core functional elements by using high-level capture interfaces.
At a practical level, the arcane nature of HDL entry can give way to simpler embedded design capture systems that raise the level of design abstraction. These might take a graphical flow diagram approach, or even use a schematic capture system where functional blocks of IP can be moved around and interconnected in a familiar way.
When coupled with an underlying system that uses software layers to segregate and configure the supporting hardware, high-level design capture systems can directly deal with the embedded elements that define product functionality. The hardware platform is not a prime consideration and can be dealt with later, when the product’s form and function have been developed to a mature state.
The separation of design functionality from physical hardware also offers a high-level of design portability where several hardware configurations are easy to explore. Because the core IP of the design–where its true value lies–is largely independent of the hardware that supports it, it can be implemented on different hardware platforms that might deliver benefits such as improved performance, a simpler implementation, or even lower costs. With each change, the re-engineering required would be minimal or even non-existent because the design’s embedded intelligence is not implicitly bound to the physical hardware.
Systems for success
Raising the level of design abstraction delivers benefits that go way beyond providing more accessible design capture systems. When the abstracted processes reach down to a system level where hardware complexity is dealt with by smart software layers, rather than merely being hidden, the process of creating a design’s functionality can be separated from the physical hardware on which it will be implemented.
Furthermore, if that embedded development system coexists with physical hardware design tools in a unified product development system, the high-level design processes can permeate through the complete design environment. A single design model is used for the entire design, so components and connectivity are reflected through all domains. For example, the high-level system that responds to a change in FPGA device can implement the reconfiguration at a physical hardware level as well as at an embedded hardware level.
The end result is a design system that streamlines and simplifies the product development process from conception though to the finished product. A high level of design abstraction, when implemented through the entire design system, removes the need to define and create the physical hardware prior to developing a product’s software-defined functional intelligence.
It is the soft functionality implemented in a design that delivers sustainable product differentiation, and not the nature of the physical hardware on which it resides. Today’s electronics design tools must provide high-level systems that unlock that functionality from the shackles of a predefined hardware platform, allowing designers to focus on creating the intelligent, connected products of tomorrow.
Rob Evans is technical market manager at Altium Ltd., a provider of electronic design automation (EDA) tools in Belrose, Australia.
