Why do embedded systems need to be programmable?

Question

According to my understanding, certain types of embedded systems are dedicated to a particular task. Why, then, do engineers not transfer all the burden of processing onto the hardware in the form of Application Specific Integrated Circuits (ASICs)? Surely, this would make the controllers more efficient? This approach should work for all embedded systems that don't need to run application software, right?

Answer 1

In large quantities (millions of copies), ASIC can be cheaper than programmable parts. On the other hand, the development of ASIC silicon costs at least an order of magnitude more than development of FPGA or microcontroller (μC) code. The great thing about software is that - almost by definition - it "enjoys rapid prototyping environment" [1]. Silicon doesn't.

Also consider flexibility. What if one wants to change the behavior of the product in the future? Making another ASIC silicon design would incur another NRE expenditure. Firmware of a programmable part doesn't require changes in silicon.

[1] Rick Dove

edit: related threads
How much does it cost to have a custom ASIC made?
What are the practical uses of ASIC?

Answer 2

I'd like to expand a bit on Nick's (great) answer.

Yes, the cost of production is usually the most important parameter of all, but, even assuming that you could design ASICs at the same cost as, say, FPGAs, this still wouldn't lead to a much wider adoption of ASICs.

The issue here is the fact that there are very few ASICs' manufacturers, and they are very busy with supplying the demand for iPhones, iPads, Galaxies, etc. This means that your (otherwise ready for production) design could be stalled due to conflicting request from one of the "giants". Usually, each project have many dependencies, and you wouldn't want to add this kind of dependency without great justification.

FPGAs and microcontrollers are small packaged "freedoms": once you've bought enough of them, you may not worry about being stuck. Even if you don't buy the required quantity ahead of time, the suppliers usually have pretty much of them in stock, therefore it is not a concern for projects which are not planned for mass production.

BTW, it is not always about the reducing the cost. Take for example oscilloscopes and logic analyzers: any high-end device (which I heard of) comes with its own ASIC (usually these ASICs are specific to a family, not to a single device). These high end devices are sold in thousands (sometimes in hundreds), but still have a custom ASIC in them! Why? Because there are companies which will pay tens of thousands of dollars for these devices, as long as they are spec'ed the best. In these cases it is worth to design ASIC for such a low volume product - the revenue margins will cover for expenditures.

Answer 3

One point not yet mentioned is that microprocessors weren't invented not as replacements for larger computers, but as replacements for interconnected discrete latches, counters, and other logic; although microprocessors today have taken over the roles that used to be played by computers built from discrete logic, they continue to work well as replacements for other kinds of logic.

In the mid 1970's, Atari designed an arcade machine called Tank, which used discrete logic to implement a game with two tanks that could drive around a playfield and try to shoot each other. It had dedicated circuitry to handle the horizontal position, vertical position, and angle of each tank as well as each player's shot, more dedicated circuitry for the score digits and playfield, circuitry to determine what part of each tank (if any) to display on each scan line, etc. Quite a complicated machine.

In 1977, Atari released a home video game console called the Atari Video Computer System (CX-2600). It contained a 6502 microprocessor, a RIOT chip (named for its content: 128 bytes Ram, I/O, and a Timer), and a relatively simple custom ASIC called the TIA (also called Stella, after the designer's bicycle). The ASIC held 20 latches for a low-resolution background pattern, two 8-bit latches for player shape, five horizontal position counters (one for each player, one for each player's shot, and one for a non-player-specific object called the "ball"), and a few mode-control and color-select latches. It also had a slot to accept a ROM cartridge. The "Combat" cartridge was a 2K ROM and it provided nearly all the functions of the original Tank arcade game, plus many other modes not included in the arcade game like alternate mazes, ricocheting shots, airplanes, etc. [The only thing Tank had which Combat did not were four fixed-position mines].

Note that the TIA did not include any hardware for displaying score, nor determining what data should be displayed on each scan line, nor indeed anything having to do with counting scan lines. The only support for vertical synchronization was a latch which the processor was responsible for turning on for three scan lines out of every 262. The vast majority of the functions that had been handled by discrete logic in the original Tank game were handled by code in the Combat cartridge.

An essential thing to note when comparing the Tank hardware with a 2600 running Combat is that most of the circuitry in Tank was sitting idle 90% of the time, but had to exist continuously regardless. By contrast, Combat was able to use the same circuitry which draws the playfield in the bottom portion of the screen to draw the score at the top; the only circuitry which had to be "dedicated" to score keeping were the two bytes of RAM used to hold the scores. Likewise the only circuitry dedicated to vertical positioning or rotation were the bytes of RAM that held the vertical positions and rotational angles for each tank (or airplane) and its associated shots.

It's possible to use multiplexing techniques to reuse circuitry even when one isn't using a processor. The game Tank (and even PONG®, for that matter) used one piece of circuitry to show the player 1 score on the left side of the screen and the player 2 score on the right side. Nonetheless, using a processor facilitates a level of circuitry reuse far beyond what would be convenient using conventional techniques.