Intel vs NEC : The Case of the V20's Microcode
Intel vs NEC : The Case of the V20's Microcode
A court case over microprocessors with far reaching implications
Featuring two semiconductor giants, a novel chip design, a four-year-long copyright lawsuit, a remarkable feat of ‘clean room’ reverse engineering and a far-reaching court ruling.
As a famous court case has been making headlines this week, I thought it might be interesting to revisit one of the most famous court cases from the semiconductor industry.
It’s about a legal battle between Intel and NEC in the 1980s over the microcode of the 8086 processor. But whilst it may be about events a long time ago, the themes are still familiar today. Whilst writing it, I couldn’t help but think about the ongoing lawsuit between Qualcomm and Arm. About how the future of both companies, and indeed others, including Intel, may be crucially affected by the results of a ruling on intellectual property protection.
The court case we’ll discuss today would also have important implications for Intel, the US semiconductor industry, its Japanese competitors and for intellectual property law in general.
Intel Sues NEC
In The Trillion Dollar Stopgap : The Intel 8086 we saw how Intel launched the 8086 microprocessor in 1978. Intel’s ‘Operation Crush’ sales campaign ensured that the 8086 soon became the most popular 16-bit processor, a position that was cemented when the cheaper 8088 variant won the CPU socket in the IBM PC.
In the late 1970s, the main competition for Silicon Valley’s chipmakers came from the biggest Japanese electronics manufacturers. Firms such as Hitachi, Toshiba, Sharp, Fujitsu, and NEC were beating Intel and its peers in the lucrative Dynamic Random Access Memory (DRAM) market.
But some Japanese competition didn’t stop at DRAMs. They wanted a slice of the growing microprocessor market. NEC started producing a series of processors compatible with the 8-bit 8080 from Intel and Z80 from Zilog.
When the 8086 was launched, Intel’s customers required ‘second sources’, other firms who would also manufacture it under licence. Several firms, including Fujitsu, Mitsubishi, Harris and, crucially for the future of the x86 architecture, Advanced Micro Devices, would make 8086/88 CPUs under second source agreements.
NEC’s soon launched their own versions of the 8086 and 8088, known, respectively, as the μPD 8086 and μPD 8088.
According to NEC, Intel had encouraged them to become a ‘second source’ for the new designs. Somewhat inconsistent with this though, NEC had needed a two-year project to reverse engineer the 8086/88 rather than using designs supplied by Intel, which would have been the usual approach with second sourcing. The ‘reverse engineering’ in this case consisted of studying, and then essentially copying, Intel’s designs.
In 1982, two years after the NEC chips were introduced, Intel sued, alleging that NEC infringed the copyright on the microcode used in the 8086/88’s. NEC had entered into a patent cross licensing agreement with Intel in 1976, which would cover any patents that protected the 8086/88’s hardware. However, that agreement didn’t cover copyright for the microcode for the 8086/88.
NEC claimed surprise at Intel’s legal action and that they believed that Intel had been previously been happy for NEC to act as a ‘second source’ for the 8086/88. NEC decided to settle, though, and in February 1983, the microcode behind the Intel designs was licensed to NEC. NEC would continue to sell their own designs, but would make royalty payments to Intel for each microprocessor sold.
More on Microcode and the 8086
The concept of microcode may be a little less familiar today than it was in the 1980s, so it’s worth taking a brief look at the concept of microcode and the 8086’s use of microcode.
Microcode is the code for an internal program in a microprocessor that implements control of various circuits and enables it to perform the sequence of operations needed to make user instructions work.
Ken Shiriff has a tremendous blog post on the design of microcode in the 8086. Quoting from Ken’s post.
“… the microcode in the 8086 consists of 512 micro-instructions, each 21 bits wide.”
“Physically, the microcode is stored in a 128×84 array. It has a special address decoder that optimizes the storage. The microcode circuitry is visible as the rectangular area bottom right the die photo below.” (This is a Siemens second source version of the 8086 but the layout is the same as the Intel 8086).
Ken’s post explains in detail how the 8086/88’s microcode works and is strongly recommended.
NEC V20 and V30
But NEC weren’t content just to produce copies of the 8086/88 under licence.
Soon after the licensing of the 8086/88 microcode, NEC started work on a new set of 8086/88 compatible CPUs. These CPUs would use NEC’s own microcode, which differed significantly from Intel’s, in part due to the very different microarchitecture of the new designs. This meant that NEC believed that they would not need to make royalty payments to Intel under the copyright licensing agreement that had applied to the earlier NEC designs.
NEC claimed that they had kept Intel informed about the work on the new designs and had even offered Intel the ‘opportunity’ to become a second source for the NEC chips. An offer that, unsurprisingly, Intel didn’t take up.
In March 1984, NEC launched these two new designs, NEC V20 and V30. The V20 was both ‘pin compatible’ and object code compatible with the 8088, and the V30 did the same for the 8086.
The 8088 in the IBM PC, wasn’t soldered to the printed circuit board, but instead sat in a plastic socket. Pin compatibility meant that someone with an IBM PC or other 8088 based machine could simply take the Intel CPU out of its socket and replace it with a V20.
The fact that the V20 was object code compatible meant that it could then run all the same programs as the 8088. Not only run them, but run them faster for the same clock speed. How had NEC been able to achieve this speed up? According to the contemporary magazine, Micro Cornucopia:
“Because of improvements in the art of chip manufacture the designers of the V-Series processors are able to include extra hardware which the 8086 family of processors doesn't have, such as an effective address generator circuit, extra internal registers, and a second internal data bus.”
And:
“These internal architectural improvements make the microcoding of many of the instructions more efficient, most notably the multiply and divide.”
How much faster was the V20 when compared to an 8088?
“Thus, at the same clock speed, the V20 operates between 5 and 30 percent faster than the 8088 and the V30 is between 10 and 40 percent faster than the 8086.”
8080 Compatibility, Power and ISA Extensions
The V20/30 didn’t stop at running 8086/88 code faster than the Intel designs.
In 1984, there were still a lot of older 8-bit systems in active use, typically running the CP/M operating system from Digital Research. Users could upgrade to an IBM PC or other 8086/88 based system, but it would mean that they would have to give up using their CP/M based software. CP/M needed an older Intel 8080 or Zilog Z80 CPU, whose instruction set was incompatible with the 8086/88.
The V20/30 incorporated a mechanism where the CPU could switch to an ‘8080 mode’. After the switch, it would interpret instructions as being for the 8080 instruction set architecture. This gave IBM PC users a way of upgrading whilst still continuing to use some of their existing CP/M software. Some CP/M software would still be incompatible as it required the richer instruction set of the Zilog Z80, but even so, this was a valuable option for many users. The NEC V20/30 achieved this simply by switching to a different microcode program, which would interpret instructions as though they were for the 8080 rather than the 8086/88.
If this wasn’t enough, the V20/30 had further advantages. The NEC chips were built using a CMOS fabrication process, meaning that they used less power than the 8088, which was built using a more power hungry NMOS process.
The V20/30 added some extensions to the instruction set, including bit manipulation and binary coded decimal instructions. If the software was able to take advantage of these new instructions, then they could give a further speed boost.
Finally, the V20 and the V30 were both very affordable, at less than $35 for a V30 and roughly $10 less than this for a V20.
NEC Sues Intel, Intel sues NEC
The arrival of a fast, cheap, pin, and code compatible competitor to the 8088 was bad news for Intel. NEC wasn’t paying licence fees for the new CPUs, and a faster version of the 8088 meant that some manufacturers might be tempted to use it rather than an Intel design.
Worse still, Intel had introduced the 80286, the successor to the 8086/88 in February 1982. There were still many users of the original 8088 based IBM PC who wanted a faster machine and who might be expected to upgrade to a machine using the 80286 such as the IBM PC/AT. If they could get a speed improvement by plugging a V20 into the 8088’s socket in their existing PC, then that could harm sales of Intel’s latest and most profitable product. At a cost of $35 or less compared to four thousand dollars for a new IBM PC/AT or compatible, it was a winning proposition.
One can even sense here that not only did the V20 threaten sales of Intel’s products and profitability, it also threatened Intel and the US’s market leadership in microprocessors.
US DRAM makers would soon cede most of that market to Japanese competitors. Intel itself would leave the DRAM market in 1986. Only later would Micron emerge as a viable US competitor. The V20/30 looked like it could be the start of a Japanese takeover of the microprocessor market.
So Intel started a campaign against, NEC suggesting to potential NEC customers that the V20/30 designs infringed Intel’s copyrights and that any firm using the chips might find themselves with facing a lawsuit from Intel.
NEC sued Intel for restraint of trade and sought a declaration from the District Court of Northern California that NEC’s designs did not, in fact, infringe on Intel’s microcode copyrights. Intel counterclaimed, seeking an injunction against further infringement of its copyrights.
At the centre of Intel’s case was their view that NEC had again copied the microcode programs in the 8088. Their position this time was subtly different from their earlier claims on the μPD 8086 and μPD 8088. The V20/30’s microcode was different to the 8088’s - even the format of the microcode, with 29 bits instead if 21, was different as can seen in the diagram below - but Intel made the case that it was derived from the 8088’s microcode and so still infringed Intel’s copyright.
Notably, Intel didn’t try to claim that the 8086/88’s instruction set itself was covered by copyright.
NEC’s case had a number of ‘fire and fall back’ positions. That is, they would make their case on certain grounds and if these were rejected, then they would fall back to another set of grounds. If Intel were to succeed, then all of NEC’s positions would have to fail.
The positions were:
Microcode programs could not be copyrighted.
Copyright has been forfeited because some Intel licensees (Fujitsu, Mitsubishi, and NEC itself) had failed to include a copyright notice on licensed products
NEC’s microcode programs did not infringe Intel’s copyrights
Any copyright infringement was necessary to perform the function that NEC needed within the V20 and V30
NEC had valid licences enabling them to use the microcode programs
Intel had misused its copyrights so they could not be asserted against NEC.
Some of these positions were unique to the Intel vs NEC case. Others though would have much wider implications for the intellectual property protection of microprocessors and other hardware.
NEC’s case wasn’t helped by the fact that one of their engineers, Hiroaki Kaneko, who had been involved in the development of the V20/30’s microcode had earlier extracted and studied Intel’s microcode from the 8086/88. And indeed, the two sets of microcode, although different in many ways, did show some striking similarities. Both had the same approach to dealing with a hardware ‘bug’ that was present in all the 8086/88 and V20/30 hardware, and both dealt with certain errors in a similar fashion.
It took a year and half of discovery and legal manoeuvres before the case made it to court. The case was heard by Judge William A. Ingram, in the U.S. District Court for the Northern District of California, over the period May to July 1986, at which point the Judge retired to consider his verdict.
The ‘Clean Room’ Backup
At this point, it was clear to the NEC side that there was a strong risk that they would lose the case, in which case they would have had to withdraw the V20/30 from the market. So the Japanese company’s US lawyers devised a fallback, which would enable them to continue to produce V20/30 style CPUs should they lose the court case.
The fallback was to produce a ‘clean room’ microcode ROM that had been made produced entirely by reverse engineering the 8088 instruction set by someone who hadn’t had sight of Intel’s microcode.
The work was split into two parts. One engineer would study the 8086/88 and produce a specification for how the hardware worked. A second engineer would use this specification to help write a new set of microcode. A ‘firewall’ between the two engineers would ensure that the second engineer had no sight of the 8086/88 microcode.
This work of writing the microcode was entrusted to Gary Davidian. We’ve met Davidian before in our post on Apple’s transitions as the author of Apple’s first Motorola 68k emulator for the PowerPC architecture.
He’d previously been employed by Data General, where he’d worked on the development of microcode for Data General’s minicomputer systems. He’d had no exposure to Intel’s designs and so was ideally placed to produce the required ‘clean room’ version of the V20/30 microcode.
So Davidian started work on the development of the new microcode in August 1986. He was given a deadline of six months, but negotiated an additional bonus for every day that he beat that target.
Davidian had access to specifications for the V20/30 a software emulator, and a series of tests that his microcode had to pass. Armed with these, he got to work at his home in Mountain View. Starting with the simplest instructions first and sending regular questions to NEC’s headquarters in Tokyo, he started work on implementation of the V20/30 instruction set.
Testing his code in the emulator against the tests he had been given, he made rapid progress and finished his work, with code that implemented the full V20/30 instruction set and passed all the tests, in just 15 days. He’d beaten the deadline by a full five and a half months.
The book ‘Inside Intel’, in a chapter called ‘Davidian’s Bonus’, has a figure of $250,000 (equivalent to almost than $750,000 in 2023) as the amount that Davidian earned from this project, although Davidian disclaimed that figure when put to him by the book’s author, Tim Jackson.
In fact, this didn’t mark the end of Davidian’s work on the project. The actual V20/30 hardware didn’t perfectly correspond to the emulator that he had been given to work with, so some further minor adjustments would be needed to his microcode. Even so Davidian had been paid handsomely for a few weeks work.
The question now was, would Davidian’s new microcode ever be used?
Four Judges
On 22 September 1986, Judge Ingram issued his partial conclusions on the case.
These found that both that it was possible to copyright microcode and that Intel’s copyrights had not been forfeited because some 8086/88 second sources had omitted copyright notices.
Davidian’s speed in developing his new microcode would soon have an impact, though. Just before Judge Ingram’s findings were presented, NEC were able to share with the Judge the results of the new ‘clean room’ work of the microcode. Davidian’s work had striking similarities with the original Intel microcode. This supported NEC’s case that any similarities between their original V20/30 microcode were necessary for successful implementation of the instruction set, striking a blow to Intel’s claim that NEC had just copied the code. Judge Ingram ordered that the new evidence from the clean room work, including testimony from Davidian, should be presented to the court.
And then the whole court process was thrown up in the air. It was disclosed that Judge Ingram held $80 of Intel stock through an investment club. NEC asked for him to be replaced. He initially protested, but after the issue had been referred to two more judges, eventually withdrew.
Judge Ingram was replaced by Senior District Judge Gray.
The Final Verdict
The trial restarted and the court heard evidence from a number of witnesses including Davidian, who was now an Apple employee, and for Intel, from David Patterson of Berkeley RISC fame.
It would take another two years before Judge Gray delivered the final verdict in the case, in February 1989, almost four and a half years after the case had started.
His first significant decision was that Intel’s microcode was copyrightable. This may seem obvious now, but the law granting copyright protection to computer programs had only been placed on the statute book as recently as 1980. Even in 1989, this was uncharted territory. From a later journal article on the case:
NEC attempted to direct the court's attention to fundamental functional differences between microcode and higher-level computer programs. The court dismissed these considerations as "semi-semantical.''
So far, so good for Intel.
Next, Judge Gray considered the implications of Intel’s failure to ensure that its second source licensees include a copyright notice for the 8086/88 microcode on their chips. This time and contrary to Judge Ingram’s earlier findings, Judge Gray found that this meant that it had lost its copyright protection for this code.
He then found that independent of this forfeiture, NEC’s microcode did not infringe Intel’s copyrights. Gary Davidian’s ‘clean room’ microcode was brought into play at this point. This new microcode also showed substantial similarities with both the Intel and NEC microcode. This led the court to decide that the similarities between the 8086/88 and V20/30 microcode in some areas might be simply because the hardware necessitated that common approach.
Finally, and notably, the court found that NEC’s reverse engineering of Intel’s microcode did not by itself constitute copyright infringement.
So NEC had won. They could continue to sell the V20 and V30 using their original microcode. Davidian’s new, demonstrably ‘clean’, microcode had played its role in helping NEC win the case, but wouldn't be needed for replacement products.
NEC did manufactured a small number of V20/30 chips with Davidian’s new microcode. Gary Davidian can be seen in the screenshot below holding one of these chips, on the left, together with, on the right, an extract from the ruling where the judge says that his microcode was ‘compelling evidence’. This is from his Oral History with the section on the NEC case starting here.
Intel too, though, would be able to take a lot away from the case. It had taken more than four years for the case to come to completion. Over that time, there had been a cloud of doubt over the legality of the V20/30. It’s very likely that this doubt had deterred PC makers from using the NEC chips in their products.
In 1985, Intel had launched the 80386 as a much enhanced, successor to the 80286. This time, Intel’s CEO Andy Grove had decided that there would be no ‘second sources’ for the 80386. It was a decision that was perceived at the time as being risky but, by 1989, was paying off handsomely as Intel took advantage of its position as the only supplier of the most advanced IBM PC compatible CPU.
The success of the 80386 would mean that Intel would see off its Japanese competitors. NEC would launch successors to the V20/30, which had a degree of success, but these would never challenge the 80386 in desktop PCs.
The case had shown that one door to replicating the 80386 and other Intel products had been closed. Firms could not simply peer at the processor, copy the microcode, and then use this in their own product.
Another door would remain open, though. If a firm could reverse engineer the operation of any aspect of the operation of a processor, including the microcode, then that would be legal. It would be a door to implementing the x86 architecture that other Intel competitors would walk through.
A brief disclaimer: I’m not a lawyer, this case we’re describing today is from almost forty years ago, so don’t base any decisions on this post or related documentation.
After the break, a short bonus for paying subscribers : links to articles by Intel and NEC’s general counsels who acted for their firms in the case, and a Harvard journal review of the case written after it’s conclusion. Each of these is highly readable and gives lots of insight into the arguments used by each side in the case.
The rest of this edition is for paid subscribers. If you value The Chip Letter,then please consider becoming a paid subscriber. You’ll get additional weekly content, learn more and help keep this newsletter going!