Editorial

The Ebb and Flow of Hardware Design Styles Shifts in tool focus allow designers to adjust the hardware-software mix. by Jonah McLeod

Over the past 25 years since I first started covering the field of electronics, I have noticed a number of trends in engineering approaches that continue to this day, waxing and waning with changes in technology. In the late 1960s, for example, Fairchild Semiconductor, now part of National Semiconductor, had a program called Mosaics, which was a first attempt at ASICs.

It never achieved commercial success because Intel announced the 4004 microcontroller. The microcontroller brought forth a new breed of engineer. Instead of building a control system from combinatorial logic using TTL circuits, designers wrote assembly language programs for a microcontroller to perform the control functions.

Examples of such applications abound, from washing machines to robotic controllers. Using a microcontroller requires a real-time operating system queuing events to be processed by the microcontroller as they occur. It arranges the events in order of their priority. Then the microcontroller processes each event serially.

This approach relies on the ability of the microcontroller to operate at much higher speeds than required by the application being controlled. The type of engineer designing such applications typically has a background in computer science. He views the design problem in terms of a flow chart and assembly language or C program code.

Wolfram Blume, president of MicroSim, observes that hardware designs of real-time control systems do not lend themselves easily to microcontroller-based solutions. Blume states that in a typical, control application the hardware must cope with multiple asynchronously occurring real-time events.

In the 1980s, new design tools and methodologies combined with affordable workstations made ASICs affordable as well as viable alternatives to microcontroller-based designs. Designers could custom-tailor hardware solutions rather than buying a standard microcontroller and programming their solutions.

This alternative approach allowed designers to build combinatorial logic to control the system. Thus, instead of a microcontroller, the engineer might build a state machine that can accommodate multiple simultaneous events. In this approach the engineer creates a schematic diagram depicting all possible events and their associated control elements. The diagram makes it easier to visualize asynchronous and concurrent events.

With the arrival of high density ASICs, however, it was believed that embedding microcomputer or DSP cores and their program ROM would be become manditory for all designers to cope with 100k-gate and larger designs. Thus, instead of combinatorial logic to control a system, these designs would again substitute program code.

The recent advent of graphics design capture tools may overcome this necessity. These tools allow a designer to describe a design graphically as a block diagram, state diagram, logic schematic, etc., that can be converted automatically into VHDL or Verilog code that, in turn, can be synthesized.

The blocks in a larger block diagram can be microcomputer or DSP cells along with their associated RAM and ROM containing the program code of algorithms for driving the microcomputer or DSP; however, the designer can also choose to implement the algorithms in logic rather than as program code. These tools again provide the designer the option of writing program code or creating logic to implement control algorithms.

Jonah McLeod is editor-in-chief of Integrated System Design.

integrated system design  August 1995