Decades ago when Microsoft unleashed Windows on the world, a colleague disparagingly dubbed the new operating environment as ‘DOS in a clown suit’. He had a point. For all the fanfare generated by Microsoft at the time, Windows was simply a GUI and application layer imposed over plain old DOS.

Yet as a front-end that abstracted the DOS operating system to a more accessible interface, Windows was a success. It removed the need to deal with the low-level complexity of the DOS command line and allowed users to work at a higher, graphical level that was more in tune with what they actually wanted to do.

Windows has now progressed, some might say painfully, to a point of sophistication that bears little resemblance to its genesis as a specialized interface to the ‘real’ operating system. As an evolutionary example of interface abstraction, it demonstrates the path from ‘clown suit’ (or more charitably, ‘graphical suit’) to an accessible working environment that connects into a broad world of applications and systems.

It also indicates that successfully abstracting a process is much more than just adding an interface layer that wraps around it or is imposed on top. Because a process rarely exists in isolation, an applied abstraction system needs to connect and respond to the system that surrounds it. Only then can its full potential be realized.

High Level Design

The abstraction systems used in electronics and software design are also familiar. In fact, so familiar they’re considered the normal, rather than abstracted ways to work. Historically, the move to integrated circuits from discrete components is a hardware example of designing at higher abstraction. ICs allowed engineers to adopt a higher-level ‘black box’ approach to design where they didn’t need to know (or care) what was inside the chips. By assuming the boxes would work within specification, they could be simply connected together as functional blocks and tested on some form of hardware development board.

Software design has progressed through a long path of programming languages and systems that all serve to free developers from the horrors of assembly language. Using the familiar implementations of programming interfaces, code syntax and compilers, software development harharnesses high level abstraction via a huge range of languages – from Pascal through to object-orientated languages and C++. Embedded application software, the lean, mean cousin of PC application software shares much of the same principles and systems.

Significantly, the upstart and relative newcomer to the electronics development process, programmable hardware, is in the early days of its design abstraction 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 – traditionally an ASIC, but now more commonly an FPGA. However the arcane nature of HDLs, often compared in complexity to assembly language, can make the task of developing embedded hardware daunting.

As a result, a range of design abstraction systems have been developed in an attempt to ease the pain. These vary widely in methodology, but are commonly schematic-based systems, graphical flow chart approaches or variants and extensions of the C language. As with the other design domains (hardware and application software), the recognizable tactic of implementing high level design systems to reduce complexity has been applied.

But there’s a lurking problem – the development of programmable hardware has a unique set of characteristics that restrict the advantages of a high level approach.

Interdependent Design, but Separate Processes

One of the defining characteristics of programmable hardware is that it is intimately bound to both the physical hardware that hosts it in a design (say, an FPGA device), and any application software that runs on it. It’s the meat in the sandwich, in effect, and binds the all three parts of the design together.

This in turn means that FPGA development cannot be isolated from the rest of what’s now a homogenous, interdependent design process. Yet conventional development tools, regardless of what abstraction layer is imposed on them, are generally separate, disconnected design domains.

The isolation of the design processes mean that crucial decisions such as hardware-software partitioning must be decided and locked in early in the design process – there’s no scope for later variations because the domains cannot interact. Design changes such moving from a soft to hardwired processor or implementing a software algorithm in programmable hardware would force a significant, and potentially costly, redesign though the domains. The result is a sequential and inflexible approach to design where physical hardware must be developed first, then followed by the programmable hardware and finally the application software. Little chance exists to explore design options to circumvent problems or achieve a better result.

Abstracting FPGA design to a higher level does not get around these limitations, and in some ways exacerbates them by making the domain and its design data even more exclusive. While programmable hardware design becomes significantly easier, it still does not allow for interaction with the interdependent hardware and software domains.

Unified Design Abstraction

What’s needed to take the concepts of design abstraction to the next level is a complete design environment that incorporates the concepts from the ground up, so that all domains can freely interact, regardless of the level of individual design abstraction. This requires a design system that’s unified at the platform level, where a single application and single pool of design data is used for the entire design process.

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 in the embedded hardware space moves beyond being 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 in a design 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, where it is manifested in all domains regardless of their level of design abstraction. IP cores or saved design can be used in the same way.

System-Wide High Level Design

Design abstraction at this level of sophistication also opens the door to a system-based approach to electronic product development. The processes are no longer isolated, isolated, and there is less need to enforce a rigidly sequential workflow since design changes are easier and incur less design disruption.

The high level development process, now implemented globally, allows designers to focus first and foremost on creating the correct end-user experience without being swamped or distracted by low level design complexity. Hardware decisions can be fixed later in the design cycle when the requirements are fully known, the hardwaresoftware partition is easier to move and a more iterative, exploratory approach to development is possible.

Using an abstracted design process that does not fundamentally interconnect to the rest of the system is like using Windows as just an interface to the underlying operating system. Without the base level infrastructure of programming hooks, system calls and APIs, Windows would revert to the clown suit metaphor – even though the suit actually looks rather nice now.

With today’s complex electronics design tasks, high design abstraction is no longer just a desirable add-on for an individual process that it may benefit. On the contrary, as design becomes increasingly complex, which it undoubtedly will, and the lines between the design domains continue to blur, ‘unified’ design abstraction is rapidly becoming essential.

This approach not only makes the next generation of electronics designs possible, but also frees designers to focus on the crucial task of creating innovative and connected designs that deliver a true competitive edge.

Rob Evans studied Electronic Engineering at RMIT in Melbourne, Australia. He has over 20 years experience in the electronics design and publishing industry including several years as the Technical Editor for Electronics Australia. Rob currently holds the position of Technical Editor at Altium Limited