Home build microcode design

[bitman]

Hello,
I'm in the last 80-90% of designing a TTL based CPU, which partly is teaching me electrical engineering stuff, and once done I hope to use to teach basic computer principles from.  But I'm now at a point where finding a solution to a particular challenge requires some input.

I'm preparing to setup the microcode in the EPROM. Currently I have 16 bits for each step in the microcode, meaning potentially 16 signals I can send to different components to enable/disable them. What I'm realizing is that's way too few - my current count is 24+ depending on how much ALU I want to do, and it may be higher if I add a couple more registers. I'm currently going through the design to see where I can consolidate and lower the number of signals I need to control, but in the end I don't think 16 will cut it. So my question is simple: Are there any tricks using latches etc. or do I need to increase the number of controls?

The latch idea bugs me because it will get in the way of enabling two registers at once (for instance). And I need a latch since I now need to set the stage over multiple clock cycles, vs. enabling all modules involve in one OP at once.  The number of chips needed will also go up dramatically using a "demux" + latches covering all 4 registers.

I've "robbed" a few antique book stores and got some books from the 70ies on the design of busses and I'm still in the process of reading the relevant sections. I wanted to ask here what a typical design would look like here. Is it a matter of adding more "bits" for the microcode to control, or do you make use of demux/latches?

[danadak]

If you add more bits to microcode this improves speed over use
of muxing/latches. Classic problem of parallelism vs serialization,
more HW vs less.


Regards, Dana.

[rstofer]

You just need to go wider.  It wasn't unusual for designs to have 128 bits of microcode width - or even more.
I would just skip trying to use decoders (4 lines from microcode into 1 of 16 outputs).  Besides, adding one more EPROM is a lot less wiring than a bunch of random logic all over the place.  It is so much easier to change microcode than to alter a bundle of wire-wrap.

Mick and Brick was considered the definitive work and is more often referenced by the authors' names than by the title "Bit-Slice Microprocessor Design"

https://www.alibris.com/Bit-Slice-Microprocessor-Design-John-Mick/book/724588

It is fairly specific to AMD 2900 series of logic elements but the ideas are universal.

Then there is Husson, better known as Microprogramming - Principles and Practices

https://www.alibris.com/Microprogramming-principles-and-practices-Samir-S-Husson/book/4350030

This book revolves around microprogramming the IBM 360

Microcode should be in RAM and loaded on boot.  That was the reason IBM invented the 8" floppy - they wanted to load microcode.

http://geekandsundry.com/the-history-of-the-floppy-disk/

Well, you can see how that worked out!  Now we have thumb drives.

I like simple.  I think I would try to get my system to boot microcode from a Compact Flash even if I had to add a uC along side. An SD would be easier to interface (less pins) but the CF has a clean programming interface - it's just an IDE drive.  In any event, I would want a way to get from the Meta Assembler running on a PC into a device that could be read at boot time.  I would skip the EPROM experience altogether.

You can't expect your microcode to work right out of the gate (pun actually intended, I worked hard for it).

Then there is the possibility of 'feature creep'  We can keep adding microcode and features until we run out of RAM.  An interesting read about bringing up a new machine:

https://www.alibris.com/booksearch?keyword=the+soul+of+a+new+machine

[bd139]

This. You can just stack the ROM/EPROMs containing the microcode as wide as you want and get as many controls signals as needed. This is so lazy it's almost worth it over discrete logic. Also you get consistent timing with ERPOMS unlike rats nest of gates. I designed one of them at university. Never got to finish the damn project though in a semester.

[woodchips]

I agree, width is what you want, 64 bits or so. It is far simpler to debug the presence or absence of a signal from the microstore than a decoded signal from a bucket of TTL. Also make the microcode in RAM, unless you have a parallel output i/f board for the computer which can read the computer microcode address and then output the correct pattern with a strobe, slow, but works fine.

If you have immediate/literal or whatever you call it now data to load a register then you need 16 bits for that straightaway.

[ale500]

Many discrete processors had multiple ROM chips for the microcode, I just wonder why do you need that today, I mean why do not use just one big E(E)PROM and several latches ? and load the latches in sequence, you not after the utmost speed, I'd guess. Just maybe less wire-wrap

[bitman]

Many discrete processors had multiple ROM chips for the microcode, I just wonder why do you need that today, I mean why do not use just one big E(E)PROM and several latches ? and load the latches in sequence, you not after the utmost speed, I'd guess. Just maybe less wire-wrap

In my case it's simple - it's 8bit PROMs so to get more width on the data side you need to "stack" them. More memory doesn't give me a wider bus.

[bitman]

Thanks - I'll widen the "bus" for microcode control. Not looking forward to having to burn/write to 4 different EPROMs making sure I mount them in the right sequence when done.

[rstofer]

Be sure to build a RAM based ROM simulator such that you can develop your microcode without actually burning EPROMs.  A few 24 pin flat cables with DIP connectors will couple the boards.

I would probably plan for at least N+1 EPROMs

If you look through Mick and Brick (page 308) you will see and excellent example of microcode written for a meta-assembler.  I haven't tried it but I wonder if it would be worth a couple of days playing around with Python to create such a thing.

Or maybe just hit up Google and get something like:
https://sourceforge.net/projects/metalasm/

[rstofer]

I assume you are going to register the EPROM outputs.  This will result in cleaner signal timing but it also allows for overlapping microcode fetch.  See page 14 of Mick and Brick.

I REALLY like this book.  I took a class in designing microcoded systems using the AMD 2900 series components MANY years ago ('83?) and this was the text.  We had to reinvent the 8086, lay out the hardware and write the microcode.  It was a lot of fun!

[danadak]

At a later time, if still of interest, Cypress PSOC architecture have UDBs (Universal Digital Blocks)
which contain a simple structure that can be microcoded via a GUI editor. Lots of fun, and it allows
access to/from the rest of the chip rich in analog, DSP, COMM....


https://duckduckgo.com/?q=udb+editor&atb=v58-5_a&iax=1&ia=videos


Regards, Dana.

[bitman]

Be sure to build a RAM based ROM simulator such that you can develop your microcode without actually burning EPROMs.  A few 24 pin flat cables with DIP connectors will couple the boards.

So I have dip-switches for both address and data bus, mostly for testing. I really did/do not want to be using those to change code on a permanent basis. I have none for micro-code at all, instead I have a small piece of code I use to generate the dump/data for the eprom. The hard work is taking the proms in and out to be written as things get completed. However, having 32dips plus logic to view/browse/enter data into 8 sub-positions per OP is well, daunting and I think that will take a lot longer than moving the EPROMs to the writer.

MY PLAN was to figure out how to develop a simple serial interface so I could load them from a USB stick or something like that, but for now that's far too advanced for my knowledge level so I'll have to do it the stupid way for now.

Note - the board has very little memory (32Kx8). If I used all potential 256 OP codes to RAM, I would have very little space left for REAL stuff. Of course I could build separate RAM module(s) for just microcode but at that point I don't get it anymore because any change I do there would have to be persisted on the EPROM anyway. I'll much rather do that structured from a PC than messing with dip-switches all over the place.

Again, I really want to thank you and everyone else for GREAT input - I've looked at the books, and once I get through a few others I bought for this purpose (70'ies publication dates too) I think these will be next

[Kalvin]

You can use a logic simulator first to try out different ideas. Much easier to edit few files instead of modifying hardware.

[rstofer]

I wasn't thinking about DIP switches, I was talking about a way to get from your EPROM socket to some other memory board that had RAM and, perhaps, a uC to load the RAM

I couldn't find premade cables but here is the connector.  Add some 24 or 28 strand ribbon cable and you are good to go.

http://www.jameco.com/z/8200-24-R-Connector-IDC-DIP-Plug-24-Pin-0-1-Amp-Use-With-Part-37760_42691.html

http://www.jameco.com/z/8200-28-IDC-Connector-28-Position-2-54mm-IDT-DIP-Plug-Cable-Mount_99670.html

[tggzzz]

I should still have a copy of Mick and Brick, plus the 2900 databooks.

If the OP wants a challenge, and to keep the EPROM narrow, and to minimise the logic count, he could consider making a serial processor. The tradeoff is lost speed, but that might be a good tradeoff.

[Kalvin]

If the OP wants a challenge, and to keep the EPROM narrow, and to minimise the logic count, he could consider making a serial processor. The tradeoff is lost speed, but that might be a good tradeoff.

Indeed, googling with magic words like
- bit-serial arithmetic
- bit-serial architecture
will return good pointers.

[rstofer]

Maybe flash memory is a little easier to use

http://ww1.microchip.com/downloads/en/DeviceDoc/20005022C.pdf

It could probably be programmed in-circuit as long as the rest of the CPU didn't go nuts (hold in reset?).

A clip like this might work.  It is for an SOIC package, not a DIP.  I don't know if it will fit.

https://www.digikey.ca/product-detail/en/pomona-electronics/6107/501-1723-ND/737553

On PCBs, I often see programming headers as just pads with vias and they are slightly misaligned on every other pin to put translational force onto the pin header that is stuck into the vias.  If you are using PCBs, you can even put pin headers along side each device.  Or, you can put one header on the end of the address bus and then just data headers along side each device.

Yes, you still need some way to generate the address, data and control signals to program the device but that should be fairly straightfoward with some kind of counter to drive the address and 8 data lines.

Those flash devices are only a couple of bucks each.

https://www.digikey.ca/products/en/integrated-circuits-ics/memory/774?k=sst39sf010a

Just the fact that the PDIP is 0.300" is an improvement!  If they can be programmed in-circuit, things get a lot better.

[bd139]

EEPROM FTW



Purely by coincidence used for microcode storage.

[BrianHG]

128k x 32bit eprom chips used to be made as a standard.  It would make bread-boarding things easy.
If you really want to save that extra wiring time avoiding wiring 2 of 256k x 16 eproms, or 4x 8bit eproms.
You might be able to find these in old surplus electronic shops or ebay.

[bitman]

EEPROM FTW

Purely by coincidence used for microcode storage.

Right, I had something similar built, but it wasn't reliable enough. Even worse, I have a couple of different EPROMs I've used in the project, and I didn't like having multiple different setups and programs created one for each chip. So I got a TL866A a while back. My software simply spits out a binary file of the size of the chip, and the minipro does the rest. It also reduces the number of times I have to insert and remove the chip from the breadboard.  Since I can only write ONE at a time, I would need additional circuits to indicate which set of data to use too. It just seemed a very fragile idea - in particular because I know I'll have to redo the microcode a lot as I learn from doing.

I probably should mention that Ben Eater (from the youtube you linked) was one of the people online that inspired me to do this project.  While he got me started with his design, I quickly diverted quite a bit from what he was/is doing.

[bitman]

Thanks guys. I'll definitely read up on the bit-serial architecture etc. but at this point that would require a full re-design of a complete model I've already put together. So that would have to wait for another project.

I should probably mention, that this is ALL built on breadboards. Replacing chips etc. isn't an issue - making it look neat is   I've basically got everything designed mandatory for a run, but I need to reduce some of the IO - there are some that are exclusive and could be reduced with a few logic gates, which should reduce the complexity in the microcode. Then I need a "POR" (power on reset) and find a way to have the rest of the PC (Program Counter) set to a non-zero value on reset (MSB must be set) - but that's about the majority of the challenges I have left except for the microcode.

Speed is not really a concern. This is primarily for MY education and once done I hope to use it to teach from too. Currently the clock I've put together maxes out at around 300kHz and I doubt I'll EVER run at that speed. As a matter of fact, I have the setup so I can do manual clock-pulses instead of automatic, to illustrate how things are working. This means I have a LOT of LEDs to illustrate state of different areas visually. So from that angle, this is not meant as something high performing - but it has to work.

[edavid]

I'm preparing to setup the microcode in the EPROM. Currently I have 16 bits for each step in the microcode, meaning potentially 16 signals I can send to different components to enable/disable them. What I'm realizing is that's way too few - my current count is 24+ depending on how much ALU I want to do, and it may be higher if I add a couple more registers. I'm currently going through the design to see where I can consolidate and lower the number of signals I need to control, but in the end I don't think 16 will cut it. So my question is simple: Are there any tricks using latches etc. or do I need to increase the number of controls?

The trick is called vertical microcode.  There are a lot of variations.  For example, you might have a 2 bit field in your microcode word that enables 4 different sets of control bit latches.  That lets you control 4 x 14 = 56 control bits with a 16 bit microcode word.   The tradeoff is that you might take up to 4 cycles to execute one microinstruction, but that doesn't seem like a problem in your case.

[C]

A PDP-11 34 was a microcoded 16-bit computer built around the 74181 & 74182.
It had no clock, It used a delay line for timing & some bits in microcode selected which delay tap to use to get to next step in microcode. This allowed for some microcode steps to be a short time while allowing more time for paths that used the 74181 or other slower logic. For a CPU memory access, a signal from memory created the next microcode step pulse. CPU memory cycle was async with the CPU stopped waiting for memory. The only problem this creates is NO Memory at address and no signal to start CPU again. This was handled by simple monostable that would create the needed pulse after a time and also generate a vectored interrupt for no memory. This was not as complicated as it sounds. It was just a microcode jump to a different microcode address when no memory existed.

While the PDP-11 only had 8 registers visible, more registers were used inside the CPU to make microcode easer and logic simpler. For example one of the hidden registers was the actual address lines that appeared on the unibus. This added two more bits to microcode, but allowed the same microcode used to do CPU instruction move r1,r2 to be used for Move PC(R7) , (hidden)address register.
In part due to hidden registers, the 8 visible registers were all the same. The microcode is what made R7 the PC register & R6 the SP.


Above I said 74181 which is hard to find these days. But if you think about it, you could create one with a rom with proper contents.

"POR" (power on reset)
Think you are thinking logic with connected microcode, big problem. Try thinking microcode with connected logic. Then POR is just starting microcode at address 0 in microcode & the microcode steps does what is needed for POR before getting to main part of microcode.

The later PDP-11 45 added some ram to microcode space & some instructions to load the microcode ram from CPU address space.. You could then build special instructions using a normal program.

Note that the PDP-11 used 4 74181's for 16-bits. The instruction set allows you to work with larger integers by using arrays in memory.
For the IBM 360, the cheaper 360's used less bits in the adder(74181 for PDP) and more microcode such that less hardware in CPU still looked like a IBM 380. Pay more and get more 74181's and faster CPU.

[tggzzz]

I should probably mention, that this is ALL built on breadboards. Replacing chips etc. isn't an issue - making it look neat is

A significant part of your education will be how appallingly unreliable solderless breadboards are; you will spend more time debugging the breadboard than your design. Problems are excess inductance and intermittent contacts.

Soldered bread boards are much better, but practical knowledge is needed  to avoid pain points.

Have fun, and keep learning

[bitman]

A PDP-11 34 was a microcoded 16-bit computer built around the 74181 & 74182.

I actually have two 74181's (not the 182) as the ALU. I wanted more than just add/subtract and I found a few old/used ones on Ebay that I'm using. Just for 8 bit data bus though (each is 4 bit). I don't really need anything bigger on that bus for this project.

As for the microcode, that was my initial question here on how wide to make it, as 16 bits was too few for the design I had, not even counting the 5 bits needed for the 74181. Adding demux and buffers will add a lot of complexity that I'm trying to avoid (the teaching part). I really would like to end up with a simple line from the microcode bit to the "feature" like enabling a register to load. It will be a lot easier to explain that way.  When I initially began, 16 bit seemed like way too much but well, it's not turning out so well. My PC register currently have 4 lines, that I think I can reduce to 3. Most of my registers have 3 states (enabled/no connection, read, write). I originally wanted 5 registers, plus PC, memory, instruction register ... things accumulated way too fast to be under 16. At least 25 right now, and that's without all 5 registers that I was planning on making.

So right now I'm trying to reduce the lines, like to a register - I think I can have just 2, one enable and one for READ (low), WRITE (high) but I'll need some more logic gates to make that happen and well breadboards are HARD to get everything to fit on   So I'm stuggling to come up with ways to reduce the number of lines I need to go to the microcode but at the same time I realized that there's NO way I can get away with just 16, unless I do as you explained with line selection etc.  The problem with that is I cannot have TWO states open at the same time. For instance, if I use 2 bits to binary represent 4 registers's enable line, I can ONLY enable one at a time. Then I need to latch it, I need more steps in the microcode to make it work and it won't be as clear what's going on.  Right now I can simply enable both registers and transfer values between them. Or enable output from the ALU and enable a register to read in one pulse. So I really like the idea of a parallel bus for the microcode as I think it shows better. The fact it's less steps isn't important. I've made it so I can have up to 8 (3 bits) steps per OP which from what I can see is plenty for my need. Funny side bar on that - I have really screwed up making an "end instruction" set - and last night as I was testing I had a big DUH moment when I realized I can mistaken the instruction register output for the micro-code instruction output. *sigh* that will be a rather large re-wiring job, but I'm happy I found it now and not later.

And that's why I use bread-boards. It's not my first "duh" moment when I have had to totally scratch or take many steps backwards to make the step forward work.  And that's really my purpose with this - realize how things like pull up/down impacts, how to read the data-sheets correct so things work and how to diagnose shorts through ICs. Even though I'm not done, I've picked up a lot of things that I'm now first reading about - and I've learned the hard way what is clearly documented in old TTL books.