re: Verilog or VHDL emulators for H{16C - some comments (about microcode)



#2

Quote:
Bennett Smith wrote:
Quote:
Does anyone know if there is microcode in the Voyager calculators or is all the functionality implemented directly in gates?

Eric Smith wrote:

You're kidding, right? I can't even begin to imagine how many gates it would take to build a hardwired HP-15C.

All the voyagers other than the 15C have a 6K*10 microcode ROM. The 15C has two of those, for a total of 12K*10 of microcode.


Eric, I think we might have gotten off on a tangent here esp. with varying definitions of 'microcode'.

You are indeed correct that to emulate the HP Nut CPU _and_ the whole calculator firmware as a complete, integral, unpartitioned state machine would be an, um, "prodigious" work and take a huge amount of gates.

But I think Bennett was trying to ask if the HP Nut CPU was really a true microcoded CPU - meaning were Nut CPU instructions in turn encoded by microinstructions in a control store ROM within the CPU? Or was it just a state machine CPU with random logic?

I am pretty sure the Nut instruction set architecture is _not_ microcoded. (Lemme know if you find otherwise. Got any die photos???)

What most HP calc folks, and even HP, call microcode - and this includes the 6Kx10 or 12Kx10 bit ROMs in Voyagers - is what I think really is more properly called just 'firmware'.

I've seen this misused in co's that make mainframe computers: these guys call ROM/EPROM resident code 'microcode' for device controllers (disks, tapes, etc.) with their own CPUs. When a big mainframe CPU disk drive needed a firmware update, it was often called a 'microcode update'.

To me, microcode isn't firmware where a user application program resides (in this case, a calculator application). I think of microcode as what Maurice Wilkes described and envisioned: it's the contents of control-store ROM or PLA(holding a 'microprogram') that defines "macroinstructions" (those viewable by a programmer), banks in or out various CPU subsystems, coordinates system timing if necessary, etc. It can drive a 'microengine', kind of a CPU within the CPU. Oftentimes, esp in later machines, the microinstructions were quite "wide" - on the order of 80 to 160 bits - to achieve parallelism and reduce number of microcycles each instruction required.

For example, the Intel 8088 CPU has (if I recall correctly) used 504 x 21 bit microwords. Some MicroVAXes used 1600x39bits of microcode. And Motorola split its control store into two layers, microcode and nanocode, to save a few kbits of ROM:

Quote:
68000 uses 544 17-bit words in its microengine and 336 68-bit words in its nanocode engine. It thus has 32,096 bits of ROM.

Some simple 8bit CPUs directly decode the instruction, bank in or out the relevant CPU sections, etc. and do not need microcoded instruction sets. The 6502 appears to be this way.

Not all microcoded CPUs use microprogram ROMs and often use PLAs instead. (This seemed to be common in Motorola 680x 8-bit CPUs.)

Because many macroinstructions (user instructions) may have common preamble or epilogue microinstructions, there are often many redundant states (or redundant fields within microwords) in the microprogram that can be 'collapsed' or 'folded'. You can think of a PLA (programmed logic array) as a ROM without full address decoding: contents stored at one address may show up in one or more other addresses as well: even though there's only one actual storage element (bit, word, etc.) actually represented it can show up in multiple places. In the past this was important to save chip area, and even increase decode speed of internal microaddress. Minimization/optimization software that chip designers used can turn a ROM array into a PLA.

Some CPUs have microcode control store RAM too to allow new instructions to be defined (or existing ones repaired ;)

True microcoded CPU implementations are disappearing as we evolve into a mostly-RISC world, esp with ARM and MIPS CPUs filling up the embedded systems space. But Intel X86 CPUs are still microcoded for some instructions. And they do have a 'repair facility' in RAM to allow bugfixes on certain instructions (I don't think hardwired nonmicrocoded instructions can be 'fixed' this way however.)

For those interested in a good read about microcoding and its history, check out the book "Microprogramming" (forget author) and any work by Maurice Wilkes. Also, check out "Bit Slice Microprocessor Design" by Mick & Brick - a rather excellent intro by some AMD guys who implemented a standard CPU architecture into a multichip 'bit-slice' CPU.


Bill Wiese

San Jose CA USA


Possibly Related Threads...
Thread Author Replies Views Last Post
  Bought a 16C to compensate a little Eelco Rouw 23 924 12-07-2013, 01:26 PM
Last Post: Eelco Rouw
  Shiny new 16C! Keith Midson 7 364 10-27-2013, 02:22 AM
Last Post: Keith Midson
  HP-16C simulator fhub 12 541 06-30-2013, 10:14 PM
Last Post: Robert Prosperi
  Emulators Olivier De Smet 5 253 06-23-2013, 09:52 AM
Last Post: Olivier De Smet
  any open source HP 10BII emulators? John 15 659 06-12-2013, 09:58 AM
Last Post: Kimberly Thompson
  Program for HP-16c... Leonid 9 423 06-07-2013, 08:51 PM
Last Post: David Hayden
  Selftest of HP-15C in 'emulators' of it Mike (Stgt) 1 159 06-06-2013, 04:27 AM
Last Post: Mike (Stgt)
  Emulators for iOS on sale today Bruce Bergman 3 256 05-24-2013, 03:54 PM
Last Post: BShoring
  New WP34s Emulators with better display pascal_meheut 13 494 04-24-2013, 02:32 PM
Last Post: RalfGeiger
  HP-67 Emulators for iPad BShoring 5 263 03-11-2013, 11:29 PM
Last Post: BShoring

Forum Jump: