Development tool evolution – hardware/firmware

Firmware development started out as a fairly simple process - a device-specific assembler (the more sophisticated ones came with a linker) and the editor of your choice.  (In my early days as an engineer, that was Brief from a company called UnderWare.  UnderWare sold brief to Solution Systems which in-turn sold it to Borland.)

Programmable logic added yet another development tool to the coding process.  Most programmable logic vendors provided free or low cost logic compilers.  Development tools such as PALASM and ABLE were distributed freely by silicon vendors or developers could purchase a tool such as CUPL from Logical Devices.  CUPL was not vendor specific so one could target different vendor’s devices during the development phase.

Back in these early days, schematics were drawn on paper using pencil, schematic symbol templates, and lettering machines. Most good engineers, when using a microprocessor/microcontroller, would actually add the hex addresses to the devices connected to the microcontroller bus.  This was a useful aid for the engineers ultimately responsible for developing the firmware.

Hand-drawn paper-based schematics served their purpose but posed a number of problems. Mistakes had to be erased and redrawn. Sometimes a majority of the schematic had to be redrawn just to fit the updated circuit change.  Then, once a schematic was completed, reviewed, and signed off by a peer review group, a set of blue lines were made and then distributed to the appropriate groups.

PCB layouts were typically done by placing pads down on clear vellum and connections made between pads with black tape of various widths.  While the printed circuit boards were being laid out, prototype circuits were built using point-to-point wiring or wire-wrapping techniques – a long and tedious task.  (Obviously not a good method for building reliable high-speed circuits.)

While the prototype hardware was being built and the printed circuit boards were in layout, firmware and software developers could, for the most part, begin developing boot code, hardware drivers, power-up self-diagnostics, and application code.  This was the fun part since no true method of instruction set simulation or in-circuit emulation existed.  Debugging was accomplished using the crash-and-burn method.  Code was burned to an EPROM (a windowed programmable memory device that could be erased after exposure to ultraviolet light).  Once a firmware bug was found, the designer would attempt a fix, re-assemble the code, burn another EPROM, and test the system again.  If it hit another bug and the system crashed, the designer would perform another round of crash-and-burn testing.  A firmware developer would keep a rail of erased EPROM’s on hand to speed up crash-and-burn testing given how long they took to erase.

As time went on, flash memory was developed.  Flash memory could be electrically erased and re-programmed in a much shorter period of time than a windowed EPROM.  This obviously sped up the development process, but for the most part it was still crash-and-burn debugging, just with a shorter cycle.  Such was the life of a firmware developer back in the early days of microprocessor/microcontroller-based product development.

Let’s get back to the hardware designers.  Drawing a schematic on paper with pencil obviously had its shortcomings.  Schematic symbol templates has to be used, and any schematic mistake had to be erased and redrawn. In some cases, a large portion of the schematic had to be erased in order to fit a corrected or modified circuit on to the final paper print.  A schematic that could be drawn in a matter of hours using a computer based schematic capture tool would have taken days or even weeks to complete by hand using pencil, paper, and schematic symbol templates.

I can remember the first MS-DOS (that’s right MS-DOS) based schematic capture program I used – OrCad. It set my company back the large amount of  $500.00.  I spent nearly three weeks hand-drawing a servo controlled X-Y medical imaging table; a part of that time was due to many mistakes and erasures.  When I drew the schematic using the OrCad schematic capture tool, I was completed in two days, with a majority of that time spent learning how to create buses and library components.  The coolest part of using OrCad was that when I made a mistake, I just deleted the component in error and replaced it with the proper one.  I could also cut and paste large portions of the circuit to other parts of the schematic in order to make it more readable. 

Besides the graphic drawing tools built-in to OrCad, it had one other great feature – the ability to create a bill-of-materials and generate it as a report easily passed off to the purchasing department or the distributor of your choosing. This was a great time saver compared to hand-generating a bill-of-materials using pencil and paper.  Changing a component or components in the schematic capture program generated an updated bill-of-material.

Now back to the PCB layout designer using tape and Mylar to lay out a board.  OrCad came up with a wonderful idea: why not have the schematic capture program also relate a PCB footprint back to a schematic symbol, generate the interconnect (netlist) and feed it into a PCB layout program.  For an outlay of an additional $500, PCB designers could toss out their tape and Mylar and generate a printed circuit board using the PCB footprints and netlist generated by the schematic capture software.

With the great schematic capture and PCB layout software being developed, it seemed that the firmware developer was being left behind using crash-and-burn development.  As certain microcontrollers and microprocessors were becoming popular, a number of hardware vendors began developing and marketing in-circuit emulators (ICE units).  The ICE unit connected between a personal computer and a pod was installed in the microprocessor’s or microcontroller’s socket (yes, these were through hole components). The ICE unit gave the firmware developer the ability to set break points, single-step through code, and modify memory/processor register values.  Even though ICE units were expensive, they could save many hours, days, or weeks of debugging over the crash-and-burn method.

As microprocessors became more sophisticated, some manufacturers added BDM ports (Back Ground Debug) to their devices.  BDM ports had many limitations compared to a standalone ICE unit; however, they were still effective debug aids for firmware developers at a much lower cost.

A new breed of hardware was introduced during the ever-expanding microprocessor/microcontroller introductions: programmable logic devices (PLDs) and field programmable gate arrays (FPGAs).   Designing with these devices opened the door for the need for even more development tools.  Schematic capture was used as a development platform during the infancy of programmable logic devices. 

As designs and devices become more complex, logic synthesis languages such as VHDL and Verilog were introduced.  With the advanced programmable logic devices available in the marketplace today, a mix of schematic capture coupled with a synthesizable logic language is the common methodology used for design. With some of the higher-end FPGAs, 8-bit and 16-bit synthesizable microprocessor cores are given away as downloadable IP by the device’s vendor.  This introduces the need for yet an additional development tool: a compiler or assembler for the processor core that will allow the processor to bolt in easily with the programmable logic device and the hardware designer’s architecture.

The next generation of development tools will combine the best of all these worlds: schematic creation, netlist generation, firmware coupling to analog and digital hardware blocks, PLD macro cells, Verilog code, and datapaths with their own small and simple instruction set (once called bit-slice processors).  All this will be coupled with a single wire debug port – an ICE unit built-in to the device’s silicon, functional and timing simulation, etc. 

Commonly used analog, digital, filtering, and firmware functions will be combined in to simple reusable modules that can be simply dropped on to a schematic, compiled, tested, and put in to production. An example of a device taking advantage of this type of revolutionary architecture can be seen in Cypress Semiconductor’s PSoC3 (8051 based core) and PSoC5 (ARM core) system on a chip.   

As hardware devices and firmware complexity continue to increase, so does our need for more elaborate and capable development tools.  By integrating tools together, developers can leverage more synergy between tools to both simplify development and accelerate time-to-market.


About the author:

Andrew Siska has been a circuit designer for the past 30 years.  He holds a BSEE and MBA and is currently working for Cypress Semiconductor as  Senior Staff Application Engineer.