Embedded software, programmable hardware, and nonprogrammable hardware can use a common design interface
BY ROB EVANS
Altium, Carlsbad, CA
http://altium-na.com
There’s probably no design engineer more familiar with working at a high level of abstraction than a software developer. Whether it’s creating PC software, embedded applications, Web services, or database systems, there’s a high-level development system and associated language to remove the pain of dealing with the native code.
Software design has progressed through a long path of programming languages and systems that all serve to free developers from the mire of assembly language. Using the now-familiar implementations of programming interfaces, code syntax, and compilers, software development harnesses high-level abstraction via a wide range of languages — from Pascal to C++. Embedded software is the lean, mean cousin of PC applications and shares some of the same principles and systems.
The abstraction systems used for developing both hardware and software in electronic design are in fact so familiar they’re considered the normal, rather than abstracted, ways to work.
The clear benefit for software engineers is a reduction in complexity and faster development times. Thanks to the use of C for embedded firmware, the need to battle with register stacks or reams of packed, sequential code is a thing of the past.
When the low-level details are handled by reconfigurable interface layers, advanced data flow capture systems can be used to develop an embedded design by defining its functional intent.
While the concepts are universal in electronic design, they only exist on an ad hoc basis, and usually within the tight focus of a specific design domain. As electronic designs increase in complexity, development times shrink and embedded intelligence rules. Software engineers need to reach into the other domains using high-level design systems.
Abstracting HDL
Where the processes used in electronic design have thrown up a new challenge is with programmable hardware devices. In this case, software is used to define the hardware, either as large sections of glue logic, or as entire system-on-chip (SoC) designs.
Programmable logic is in the early days of its design abstraction and high-level design evolution. Hardware description languages (HDLs) are used to describe the design at a register (RTL) level, which is ultimately synthesized to a gate level for implementation in the selected device — an ASIC, or now more commonly an FPGA. But the arcane nature of HDLs, often compared to assembly language, can make the task of developing embedded hardware daunting for anyone who is not an specialist.
A range of design tools have been developed in an attempt to ease the pain. These vary widely in methodology, but are commonly schematic-based systems, graphical flowchart approaches, or variants and extensions of the C language. They allow more players, such as software engineers, to create embedded hardware.
Consider, for example, a high-level embedded design system based on a variant of a C. Such a system offers software engineers who have a working knowledge of hardware design the opportunity to create embedded hardware using a familiar language and approach. This process tends to reflect the sequential nature of software however, rather than the parallel concepts of hardware, and is mostly used for sections of the design or as translated software algorithms — taking a systems approach to the design is another matter.
Whichever high-level system a software engineer might use for embedded hardware design (flowchart, schematic, or C-translation, etc), the opportunity exists to create large, relatively complex “soft” hardware systems to support the engineer’s own software routines and functions. Or perhaps ultimately, a complete product design.
Using the right design environment, high-level design processes can be used to develop entire FPGA-based systems in a simple and flexible way, where the underlying hardware architecture complexity is handled by the system.
Common systems available for raising the design abstraction of programmable logic design mostly exist as separate, disconnected methodologies that do not address the interdependent nature of the overall SoC design process. The dependency between the domains is amplified by the presence of programmable hardware, which typically hosts the application software and is itself hosted by the design’s physical hardware.
A cohesive approach
What’s needed to take the concepts of design abstraction to the next level is a product development system that brings together the design domains into one unified application that uses a single design data model. In this way, embedded software, programmable hardware and other hardware can use a common design interface and model of the design data across all domains, making product development one cohesive and connected task.
Embedded hardware design can then become an integral part of the design process that reaches into the hardware and application software domains. Changes in any domain will modify the single collection of data and become instantly available in the other domains, and any high-level design processes are inherently ‘understood’ by the rest of the design system. Design abstraction moves beyond a simple, isolated layer that sits on top of the normal process to one that interactively permeates though the complete design system.
With such as system in place, typical tasks like implementing a USB stage are vastly simplified. In this case, the USB stage is likely to have elements that need to be incorporated in all domains — connectors and interface hardware in the physical space, bus interfaces in programmable hardware, plus drivers and protocol layers in the application software domain.
The single pool of design data, which includes library parts, holds a single model of the USB block that incorporates all elements. The model can be simply dropped into the design, using a high-level graphic-based capture system, where it is manifested in all domains regardless of their level of abstraction. IP cores or saved designs can be used (and re-used) in the same way.
The advantages of working with a single model flow to all aspects of design. The high-level design possibilities permeate all domains and enable a practical software-centric approach to electronic system development.
Soft design on real hardware
The next step is where this system is coupled with a low-cost FPGA hardware development platform that includes support hardware, common I/O systems, and plug-in peripheral boards that can be changed at will. Intelligent communication between this hardware platform and the high-level design software allow direct interaction with all parts of the development board, rather than just providing the basic ability to program the FPGA. The peripherals can be swapped on the fly, with the software automatically reconfiguring the interface layers and configuration files as required.
For all engineers, and in particular software developers, high-level systems can be used to develop and explore design options in real time, and on real hardware. That hardware could conceivably become the final product in some circumstances — such as low product production runs. This places a software engineer in the unique position of being able to rapidly develop a complete product, or at least a proof of concept device.
What’s even more compelling is the prospect of off-the-shelf hardware that is directly supported by both the design software and the hardware development platform you use to develop and test the product. Design carried out in that environment can then directly translate into the final product.
With this approach, crucial design decisions can be made much later in the design cycle, and the defining soft elements can be updated at any time — even after the product has been deployed in the field. The immediate hardware decisions are removed from the early design process, freeing designers to focus of the embedded aspects of the design that define its function and capabilities. The hardware will ultimately be selected to accommodate the needs of the design’s soft elements, rather than the other way around. ■
Advertisement
Learn more about Altium
