Why did later CPUs use microcode instead of PLA's?

Question

If you look at a die photo of a 6502, about forty percent of the chip is taken up by what's obviously microcode, both by its regular structure and by the obvious need for such from the instruction set, which has some relatively long instructions that need to do half a dozen things in exact sequence.

But it's not a ROM; as explained in the answer to How was microcode implemented in retro processors? it's actually a PLA, which differs from ROM in that it "allows partial decoding, one entry can fire on different instructions. For example, all instructions loading the second byte as immediate share one single PLA entry (microcode line). In comparison with textbook microcode engines, this is equivalent to a kind of compressed microcode."

Such compression is obviously useful. Die space is expensive; reducing the space taken up by microcode means you can make the chip cheaper, or spend the space adding more features, more performance or some combination thereof.

As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

Why did later chips not also use PLA's and thereby gain the advantages of compressed microcode?

Answer 1

But it's not a ROM; [...] it's actually a PLA

Then again, a ROM and a PLA is essentially the same technology. What differs here is not only the decoding, but that in case of the 6502 only the decoding part is present and it's not monotone.

Such compression is obviously useful. Die space is expensive

True. But it's worth to note that the cited answer says "a kind of compressed microcode" as it's not simply compressed microcode. Its savings from leaving out the data part and as well from structuring the instruction set around this feature. 'Simple' microcode leave full freedom to the instruction set designer about how to encode, aka what bit pattern results in what instruction to be taken. The 6502's way relies on arranging them in a certain structure to take advantage of the 'compression'. Not doing so will result in zero savings.

As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

• Most important here: a cleaner design (process). With classic microcode hardware design and instruction set design becomes independent or at least less tight coupled. Late changes can be included without much problems, especially if the ROM is designed a bit larger than the bare minimum.

• Next, the way of 'compression' used in the 6502 delegated the work to the random logic activated by each line. Where standard microcode output has dedicated functions for all blocks handled by all instructions, the 6502's way mangles this up. In some way it can be seen like spaghetti code in BASIC. Great approach for a simple task, but it soon gets out of hand when the job gets more complicated. What works for the rather simple instruction set of a 6502 with just 56 (essentially only 25) instructions and 13 (8) addressing modes doesn't work the same way for either of the 16 bit CPUs with their huge number of instructions and addressing modes.

  Any change here always means also a change in random logic, not just microcode data.

• Which brings the issue of complexity. Where an instruction set like the 6502 features and it's execution units can be optimized and 'compressed' by hand in a reasonable time, it will be a gigantic task to do the same for a 8086 or 68k. Not saying it can't be done, but the gain will be much smaller and the risk of screwing it up much higher.

  Of course it may be possible to handle the additional complexity of an 8086 or 68k by a comparable small PLA, but it will most definitely increase the random logic several times, not only eating up much of the savings (or even adding) but increasing the needed effort exactly in the area point where it's hardest

• Last but not least, it's an economic decision between effort in design, cost of chip space and risk of problems/failure:

  • A tightly fitted system like for the 6502 simply costs more engineering time than using an rather standard microcode approach.
  • Saved chip space is always in relation to technology. While saving a small group of transistors, like 13 for a PLA row, was a big deal for a 6502, doing the same for a 8086 or 68k would have a neglectable effect.
  • Using an 'unconventional' approach like the 6502 did increases the risk of failure. Heck, even MOS did mangle it up with the first rund, screwing the ROR.

Especially the last points are nothing one wants to have on a small budget project meant as a short time stop-gap measure, like the 8086 was (*1). Design situation on the 6502 was a different one. They had even less funding, but way more time on their hands - and more pressure to save on size.

Long story short: Cost, time and risk outwights any possible gain.

---

P.S.: With today's tools it might be possible to have a random logic version of either chip generated, eventually creating faster versions. But for top end results, the microcode as abstraction layer persists - sometimes even on multiple levels.

---

*1 - The 68k in contrast is a typical Motorola product - by the book - so microcode it is anyway.

Answer 2

Two interconnected moments in history with the popularity of microcode in microprocessors need to be distinguished:

• Firstly, the ratio of price, volume and speed of various types of memory;
• Secondly, the ratio of manual labor and the development of automation, including the theory of compilers.

The heyday of the microcode came at a time when the means for automatic development of integrated circuits were just beginning to flourish, and manual development on the ruby ​​film of processor circuits with tens of thousands of transistors was already too slow.

At the same time, the cost of RAM, and at all levels - from SRAM processor registers to DRAM RAM itself was still very high, which required a high code density. High code density was often achieved by manual optimization at the level of assembler and even machine codes, which required some convenience and human readability from the instruction set / processor architecture.

An additional layer of some abstraction between the actual executive blocks of the processor and the code was a generally accepted compromise.

And then the RISC revolution happened.

PS

It is also worth mentioning the problem of debugging processors.

Satisfactorily prototyping the microprocessor on assemblies of ICs of small and medium integration when using PLA in the late 70s was difficult due to the physical limitations of the method. Emulating software on mainframes was difficult to impossible because of the dampness of software and the size of RAM, slowly and also took a lot of time. Debugging directly on silicon required many production cycles on the fab, which resulted in many weeks of debugging.

Using microcode brought some of the debugging problems to a different, simpler level - in prototypes it was possible to replace the firmware ROM with a (even external) SRAM module and quickly identify / correct errors.

Answer 3

For those interested in the hands-on use of microcode, including how to implement a CPU (1802 - which was NOT microcoded, but a FSM control unit) and a display controller, I developed a compiler that generates the [horizontal] microcode and instruction mapper memory. https://hackaday.io/project/172073-microcoding-for-fpgas

Answer 4

As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

This is simply not true. 68000 CPU used a combination of PLA-driven decoding and ROM-driven microcode engine. Look https://dl.acm.org/doi/10.1145/1014198.804299 for reference (remember that there is Sci-Hub at your service if you know DOI: https://sci-hub.st/https://doi.org/10.1145/1014198.804299).

Another example is LSI-11 chipset WD16xx, where there are also microcode PLA to decode PDP-11 instructions (particularly to get starting point in microcode ROM) and microcode ROM (all in different chips) to execute micro-sequences.

Modern amd64 CPUs first do hardwired decoding, then go into microcode ROM (or RAM, partly) to generate micro-op sequences for some architectural instructions.

The general idea behind PLA vs ROM microcode is the following: with PLA (or just logic) you can easily decode instruction and group similar but differently-coded instructions in a single bunch, and this is very costly to do with just ROM microcode alone (look at 68000 with 16-bit opcodes). Alternatively, executing sequences of internal operations is better done with ROM microcode, hence both technologies are usually combined (starting from the venerable 68000 chip and LSI-11 chipset).

8-bit CPUs are a special case, where both ROM or PLA would be approximately the same size alone, and the natural choice is to have only PLA, which also does most tasks of ROM with the help of a standalone sequencer, as it is in 6502.

The answer to the question would be then "No, PLA- (or generally, logic-) directed decoding is still used, along with ROM- (or RAM-) based microcode sequencers."