The concept of applying a higher level of design abstraction to creative and engineering processes is so closely familiar that we probably take it for granted. From NC machines to SQL database systems, a high-level approach to capturing the design or operational intent of a system is universally accepted as the way it’s done.
The benefits, of course, are substantial and easily justify the task of developing the specialist skills needed to use the high-level systems. By inserting translation layers between the fundamental nuts and bolts of the system and the user, systems that raise the abstraction of creative processes dramatically reduce the level of complexity faced by the user and help to speed the overall process. Crucially, such systems also offer the opportunity for more users to “play” in that arena, since a fundamental knowledge of the underlying technology is no longer essential.
In the electronic engineering world, the obvious example is software development, where the move from using assembly code to high-level languages like C++ has revolutionized the way embedded software is created for processor-based systems. Any initial resistance based on the increased size of the resulting code was soon offset by larger, lower-cost system memory and faster processors, leaving software engineers to benefit from a reduction in complexity and faster development times. Thanks to C, the need to battle with arcane register stacks or reams of packed, sequential code is simply a thing of the past.
The way electronic products are developed and the technology we use has rapidly evolved, though. And as history has shown, technology changes have a habit of shaking up the way things are normally done.
EMBEDDED DESIGN COMPLEXITY
The advent of low-cost, large-scale FPGAs has opened a whole new range of possibilities for embedded-system developers, where complete embedded systems—both the hardware and software—can be hosted within the programmable realm. While software is developed in a familiar way, the process of creating embedded hardware typically involves working with a hardware description language (HDL) such as VDL and Verilog, and applying a level of knowledge about the underlying hardware architecture.
Developing embedded hardware with these systems, in a design flow that has largely been adapted from the chip design industry, means acquiring specialist programming skills and dealing with a new level of design complexity. For embedded system developers with a limited knowledge of the hardware technology they are working with, an HDL solution imposes significant barriers to embedded hardware design.
As already evident in other design capture environments, raising the abstraction of what is a complex process should yield the benefits needed to free more engineers to create embedded hardware platforms. Unlike the systems that have benefited from doing this, however, there’s an important difference in the development process for embedded hardware—it doesn’t exist in isolation, but is fundamentally linked to the other parts of the design process.
What this means in practice is that the embedded hardware configuration has a direct and inescapable link to both the design’s software and its underlying physical hardware. For example, changing the type of embedded processor or peripheral function block is very likely to influence an FPGA’s pin configuration, and the embedded software it hosts. As you might expect, the converse situation is equally true, where changing a hardware device such as the FPGA directly affects the embedded part of the design and how it responds to the embedded software.
High-level design approaches are needed to make embedded hardware design an accessible and connected part of the overall product development chain. There are a number of approaches to achieving this goal. Moreover, in a similar way to the adoption of high-level software languages, if the resulting embedded code increases in size, it’s easily offset by more capable, larger devices. But while the introduction of abstraction or translation layers is likely to make the design capture process more user-friendly and efficient, system integration issues are another matter.
For example, take a high-level embedded design system based on a variant of a conventional software language like C. Such a system, which inserts a C translation layer, offers software engineers with a working knowledge of hardware design the opportunity to create embedded hardware using a familiar approach. It is, however, a largely disconnected methodology for embedded hardware design that doesn’t address the interdependent nature of the overall design process.
Raising the level of design abstraction in this way can satisfy a subset of software engineers, but tends to complicate the overall process by introducing a specialized development environment that’s disengaged from the design development workflow. And just like conventional HDL entry, a C-based approach still requires software engineers to have a working knowledge of hardware design, and hardware engineers need to learn a specialized software language.
What’s really needed is an embedded development system that raises the abstraction of the embedded (or “soft”) elements of the design process in ways that suit all engineers—system, software and hardware. Also, it must make that process an intimately connected part of the overall product development workflow.
A COHESIVE APPROACH
The answer is to move away from existing design methodologies that have their roots in a traditional board-centric approach, where separate tools are used to create the hardware and software elements from a “circuitry-up” perspective. This alternative is based on a system that allows design engineers to work with functional blocks of IP at a high level. These elements are pre-verified and pre-synthesized IP blocks from a system library or even repackaged elements from previous designs.
The actual interface is based on design capture systems that present familiar methodologies to engineers from all disciplines, so that functional design elements can simply be connected together through all stages of the design process. Schematic-based entry, a comfortable design environment for hardware engineers, offers an interface where IP “components” are placed in the design from existing libraries and wired together in a familiar way (Fig. 1).
In such an approach, the underlying gate-level source and FPGA architecture considerations are taken care of by the design abstraction layers within the system. With this system in place, the potential then exists to introduce further levels of design abstraction that move one step further from a schematic approach, where the key elements of an embedded processor-based design are represented as simple graphical elements or icons (Fig. 2).
These simplified elements are connected together in a simple flow-chart approach, with individual bus interface connections—the “wires” in effect—taken care of by configurable abstraction layers within the system. The design capture process in this case centers on a more software-centric approach of creating functional interactions between elements, rather than wiring hardware blocks together.
Reprints
