I'm officially building a microcode-level 68000 core

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Fri May 17, 2019 1:59 pm

Thank you very much for your help. Yep, it sounds like my image tracks with what you just described. Thanks for clearing up the meaning of each layer, that makes a lot more sense now. You've answered some more of my questions already too, I was going to ask how you picked out the depletion mode vs enhancement mode fets. Sounds like the answer is "educated guesses" :). Looks like the buried contacts must take a fair bit of squinting to pick up in all cases too. The gradient on the edges in the third delayer pick gives it away fairly well though. I suppose we're lucky it's possible to figure out these things by eye at all.

I must say, I'm impressed in how controlled the de-layering process seems to be. Decapping an IC is hard enough (I know, I tried it a bit in my backyard. Still got the fuming nitric acid in the garage to prove it), but doing such clean, controlled delayering of the physical surface is something else entirely. Must be just as much an art as a science.

Now that I understand the physical analysis from the die (well enough for now anyway), I'm going to switch back to the schematic analysis. I attempted to decode the microcode store, but the branch addresses were screwy, so something wasn't right. I understand the physical layout and arrangement of the rows/columns in the microcode/nanocode store, but unless the data I was using was wrong, I had something twisted about the branch target addresses. Is this file accurate?:
https://og.kervella.org/m68k/microcode.txt
I was lazy, so I sucked that in and spat it back out into microinstruction listings (just the 17-bit microword data portion), but it didn't check out fully. I only spot-checked some rows/sections, but the bits seemed to match what I could eyeball from the die shots. When I started delving into parts of the macroinstruction decoding logic is when I spiralled into the realm of trying to relate the schematic back to the die, which is how I ended up here.


I'll finish off the patent transcriptions next probably. I'd like to think it'll be this weekend, but I've got to do major work on one of my cars tomorrow, which I estimate should take about 4 hours, so with my estimates that'll probably mean it'll be finished by 6pm on Monday. After the patents, I'll have a fresh look at decoding the microword store. I've got a stack of questions shelved about microcode, but I'll save them until I've got a bit further along. I know you've already trod this ground and your tools can spit out full instruction listings for each microinstruction (what's your confidence level in that output by the way? Very high, or is it only so-so?), but I'm going to at least make sure I'm confident in the way the instructions are addressed and the way branching operates at the low level first before moving on. I'll defer to your work and ijor's work when it comes to aspects like the individual control lines and the ALU operation modes though, I really don't want to trace all that out.

galibert
Newbie
Posts: 7
Joined: Thu Jan 31, 2013 12:55 pm

Re: I'm officially building a microcode-level 68000 core

Post by galibert » Fri May 17, 2019 3:38 pm

Which patent transcriptions? They're somewhat different from the real thing, at least the nanocode tables.

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Fri May 17, 2019 11:42 pm

The US4325121 patent is the main one I'm referring to right now, with the appendices that list microinstruction details. While things changed in the final product, enough things should match up to allow me to correlate proper names for various registers/microinstructions, while also serving as a sanity check on the manually decoded microinstructions from the physical die. With all the instruction details transcribed from the patent, I can spit out decoded instructions from the die in a common format, and easily highlight the differences between the two.

stinkz
Newbie
Posts: 4
Joined: Sun Apr 21, 2019 2:25 am

Re: I'm officially building a microcode-level 68000 core

Post by stinkz » Mon May 20, 2019 2:04 am

Well I may as well start to share what I've been working on. For the past few weeks I've been banging my head against my computer trying to write a simulator for galibert's netlist.
On Friday I got frustrated not understanding what was going wrong with the sim, so I wrote a visual layer for the sim, and just now I think I finally figured the sim out.
No source code sharing just yet, it could use a little clean up first.
Attached is a pic of the clock generation section "working", at least I think it's working. It's a little ugly when aliased from minification, it looks much nicer when zoomed in a little bit more.
White squares is VCC, black squares is GND. White lines are powered lines, black lines are grounded lines, grey lines are floating lines (not pictured). Bright red transistors are on nmos, dark red are off nmos, bright blue is on ndepletion, dark blue is off ndepletion (not pictured). Bright green are charged capacitors (not pictured), dark green are discharged capacitors. Big grey squares are pads.
Attachments
m68ksim01.png
m68ksim01.png (14.91 KiB) Viewed 1255 times

ijor
Interested
Posts: 15
Joined: Fri Nov 16, 2018 11:46 am

Re: I'm officially building a microcode-level 68000 core

Post by ijor » Mon May 20, 2019 4:07 am

A few comments:
galibert wrote:
Thu May 16, 2019 6:28 pm
Is everything in the micro/nanocode? Not at all, by far. There are roughly 200 control signals to the EU, the registers, etc. There are more or less 70 signals coming from the micro or nanocode (68 from nano plus the two bus access type from micro). the 70->200 expansion is controlled by a ton of PLAs keyed on the IRD register. Plus other things are fully PLAd, like the exception/interrupt vector addresses.
This is mostly just for the record because I'm sure Olivier knows it: The nanocode uses "only" 66 bits. The nanostore allocates physically 68 bits, but two bits are unused. I am sorry that I am too lazy to post die pictures. But if you look at the die you can see two metal traces coming from the nanocode, going to the execution unit but not connected to anything.

I also think that the 70->200 figure might be misleading. Many of the signals are either a simple decoding of the microcode, or an expansion of a register field. But yes, of course, I agree that not everything is in the microcode. You can check my irdDecode module and the s_irdecod structure to have an idea.
Nemesis wrote:
Fri May 17, 2019 9:49 am
Image
Here we see ird.0 coming in down the left then up from the bottom, and nird.0 going out on the right.
This schematics of an inverting SuperBuffer is not correct. It might be counter intuitive, but Nmos Superbuffers use a depletion mode pullup at the last stage, not an enhancement mode one as illustrated here at the top right. Not very important for our purposes unless you perform an analog analysis or a Spice simulation though.
Nemesis wrote:
Fri May 17, 2019 11:42 pm
The US4325121 patent is the main one I'm referring to right now, with the appendices that list microinstruction details. While things changed in the final product, enough things should match up ...
The actual microcode seems to be very similar, almost identical, to the one described at the patent. I say "it seems" because I didn't perform an exhaustive comparison (may be Olivier did?). I don't have an easy way to perform such a comparison mostly because I don't have a corrected transcription of the patent.

The main differences are, as expected, at the exception microcode, the Stop instruction, and the DBcc one. DBcc obviously is not present at the patent at all, and the other two were always obviously wrong even before looking at the die. Most addresses were also reshuffled.
With all the instruction details transcribed from the patent, I can spit out decoded instructions from the die in a common format, and easily highlight the differences between the two.
That would be nice. But do note that the patent microcode is somewhat misleading. There are some things that the patent microcode includes that aren't really encoded at the microcode. And there are some thing encoded at the microcode that aren't always specified at the patent. In other words, you can't extract the whole microcode listing, as it is in the patent, just from the die. And neither you can't perform a full encoding from the patent listing (not even after correcting for errors and missing). Of course, this should not stop you from your goal. You just would need to make some manual adjustments.

Btw, add the following book to the bibliography, which I believe it was already mentioned at other threads here:
https://www.amazon.com/Microarchitectur ... 940108775X
http://github.com/ijor/fx68k (68000 cycle accurate FPGA core)

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Wed May 22, 2019 3:41 am

I've finally completed the microcode transcription from the 68000 patents. It was slow and boring and took forever, but it's done now thank goodness. My primary sources were EP0019392B1 and US4325121. Hopefully some of you will find the result useful. Now that the data is in a clean digital form, it'll be easier to process and compare with the final device.

Here's the full, raw transcription of all 92 pages of "Appendix F", laid out in the same format as its provided in the original patent documents:
http://nemesis.exodusemulator.com/M6800 ... rocode.txt

Here's a reconstruction of the named sheets in Appendix F. Best printed in A0, but A3 is readable:
Sheet A (txt)
Sheet A (pdf)
Sheet B (txt)
Sheet B (pdf)
Sheet C (txt)
Sheet C (pdf)
Sheet D (txt)
Sheet D (pdf)
Sheet E (txt)
Sheet E (pdf)
Sheet F (txt)
Sheet F (pdf)

While the above forms are nice to look at and are easy to correlate back to the patent documents, they're a pain to work with. Here's a flat list of all the content in Appendix F, in a form that's easier to process, sorted by microcode address. A couple of corrections have been made to fix obvious errors:
http://nemesis.exodusemulator.com/M6800 ... t List.txt

There's more in the patents than Appendix F though. Here's a csv transcription of Appendix A, which is a simple listing of each microinstruction, with additional information not contained in Appendix F:
http://nemesis.exodusemulator.com/M6800 ... owords.csv

Here's something that's not a transcription, but is a very quick, very dirty stitch together of Figures 10 and 11, listing the nanowords and microwords, which is suitable for printing at A3:
http://nemesis.exodusemulator.com/M6800 ... Table.png
http://nemesis.exodusemulator.com/M6800 ... Table.png

Finally, here's the most useful data. I've sucked in all the information in Appendix A and F, cross referenced with Figure 10 and 11, tool-checked everything for validity, and unified the data together into one simple csv:
http://nemesis.exodusemulator.com/M6800 ... action.csv
And for convenience in viewing, here's a Google Docs version:
https://docs.google.com/spreadsheets/d/ ... H2-ux3gjNc

Some notes on the unified data:
-There are two kinds of annotations used in the top right of the nanoword content field in Appendix F. I've brought this data into the csv, but I don't know what it represents at this stage.

-"trap0" is used as a branch target in Appendix F. This instruction isn't defined anywhere else. Cross-referencing with Appendix A shows the branch targets that refer to "trap0" should be "dvur2", which is defined in both Appendix A and F. The unified data has this adjustment made.

-The microinstruction at address "328", appearing in Appendix F on sheet A, row N, column 4, curiously has a blank label and origin. There are two defined instructions from Appendix A which are missing from Appendix F, which are "mmaw2" and "mmrw2". The correct label for the blank entry at "328" is "mmrw2" in the context of Appendix F, as that is what other instructions that branch to it or share nanocode with it refer to it as in Appendix F. Things are not clear cut however, as in Appendix A, both "mmaw2" and "mmrw2" are defined, and some of the branches that were assigned to "mmrw2" in Appendix F are assigned to "mmaw2" here. In Figure 10 which shows the microinstruction addresses, "mmaw2" is in the slot at "328", while "mmrw2" is shown in slot "021", which is unreferenced in Appendix F. In Figure 11 which shows the nanoinstruction addresses, both slots "328" and "021" list "mmrw2". Long story short, it appears this microinstruction was split, and I consider the information in Appendix A to be the most credible/recent here, so that's what I've taken in the unified data set.

-"popm2" doesn't have any branch targets listed in Appendix F, despite the listing clearly showing it should have some. Appendix A provides the missing list of targets, but not the conditions under which they are taken. Both these fields appear separately in the unified data.

-Appendix A and F disagree on the "Type" column of "mpol2" and "peax4", with one claiming "dbi" and the other claiming "db" for each of them. I'm not sure at this stage which one is correct. I've arbitrarily taken the values from Appendix A in the unified data set.

-The "Origin" field for the following instructions differs between Appendix A and F: dvur2, leax2, stmx2, stmx3, leax3, dvum4, dvumz, stmr1, push1. I've arbitrarily taken the values from Appendix F right now. I haven't done a thorough cross-reference with Figures 10 and 11, which might clarify the situation.

-Figures 10 and 11 contain some additional unidentified annotations. Figure 10 contains a code in the top right for each microword, such as "M1", "MB", "MB2", etc. Figure 11 can contain a "d", "b", or "m" note next to the nanocode label, with "d" sometimes combined with "b" or "m". I haven't pulled these annotations into the unified data at this stage.


That's basically all I've been doing since last week. I haven't had time yet to even look at this data closely myself, let alone compare it with the microcode/nanocode in the final device. I'll be giving my brain a rest for a day or two, then I'll get back to it. The next thing I want to do is do a write-up on how microinstructions are addressed, show how to decode the microcode from the die in the final product, and then compare the microinstructions listed in the patents with the microinstructions from the released 68000 processor.

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Wed May 22, 2019 3:56 am

stinkz wrote:
Mon May 20, 2019 2:04 am
Well I may as well start to share what I've been working on. For the past few weeks I've been banging my head against my computer trying to write a simulator for galibert's netlist.
...
Great work! I'm interested where this ends up. It'd be fantastic to be able to have something like that working. In particular, I want to be able to tie something like that into an emulator alongside a higher level 68000 core, run a program, and have it alert on any differences of interest. I could use that to verify timing for example, but the same technique could also be used to look for differences in flag calculations or any other aspect of correctness in basic emulation.
ijor wrote:
Mon May 20, 2019 4:07 am
galibert wrote:
Thu May 16, 2019 6:28 pm
Is everything in the micro/nanocode? Not at all, by far. There are roughly 200 control signals to the EU, the registers, etc. There are more or less 70 signals coming from the micro or nanocode (68 from nano plus the two bus access type from micro). the 70->200 expansion is controlled by a ton of PLAs keyed on the IRD register. Plus other things are fully PLAd, like the exception/interrupt vector addresses.
This is mostly just for the record because I'm sure Olivier knows it: The nanocode uses "only" 66 bits. The nanostore allocates physically 68 bits, but two bits are unused. I am sorry that I am too lazy to post die pictures. But if you look at the die you can see two metal traces coming from the nanocode, going to the execution unit but not connected to anything.

I also think that the 70->200 figure might be misleading. Many of the signals are either a simple decoding of the microcode, or an expansion of a register field. But yes, of course, I agree that not everything is in the microcode. You can check my irdDecode module and the s_irdecod structure to have an idea.
The patents talk about this a fair bit as well. It talks about the 68-bit nanocode being expanded to "approximately" 180 "control points", and describes how IRD is used to key behaviour as well. Would it be an accurate statement to say though, putting exception handling to the side, that given an accurate IRD register state (and other registers of course) and the microcode/nanocode, all the data is present in one form or another to determine the actions that the processor would take when executing a microinstruction?
That would be nice. But do note that the patent microcode is somewhat misleading. There are some things that the patent microcode includes that aren't really encoded at the microcode. And there are some thing encoded at the microcode that aren't always specified at the patent. In other words, you can't extract the whole microcode listing, as it is in the patent, just from the die. And neither you can't perform a full encoding from the patent listing (not even after correcting for errors and missing). Of course, this should not stop you from your goal. You just would need to make some manual adjustments.
Could you expand on what some of those things are ijor? I haven't had a close look at what happens to the nanocode after decoding, so I'm not sure what's missing at this point from the patent docs. If you could highlight the information that's missing from the patents, or the information that's extraneous and not encoded (apart from the label of course), that'd be helpful.
Btw, add the following book to the bibliography, which I believe it was already mentioned at other threads here:
https://www.amazon.com/Microarchitectur ... 940108775X
Have you come across a pdf of that by any chance? It was published before I was born, so I don't think there's much of a claim for lost revenue here.

r57shell
Very interested
Posts: 477
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: I'm officially building a microcode-level 68000 core

Post by r57shell » Wed May 22, 2019 3:19 pm

Nemesis wrote:
Tue May 14, 2019 4:48 pm
I wrote this program, dubbed "Schematic Explorer", which can directly load in the schematic svg, and allow you to rotate and zoom in easily, while also throwing in color, tooltips, dynamic highlighting of lines on mouse-over, and the ability to add custom comments and "annotation" overlays to document the layout, which gets saved to an external xml file along side the schematic. I threw this tool together in C# + WPF, because I know those environments well, and what else can you build something like this in with around 1000 lines of code?
Two years ago I had interest in this M68k die. I did even make some tools, compiled some of galibert's stuff.
I remember I've add zoom by cursor into galibert tool, and allow to draw text in any zoom mode.
At the time you might see text only in biggest zoom level, so I've changed it.

This is my viewer that should help to trace lines:
https://youtu.be/4ApZXbNOAEs
this is screens of very first versions, where I set all lines to different colors:
Image
Image
It was done on python, using OpenGL. For OpenGL this amount of lines is just piece of cake.
Selection is done by 2d array of cells, and for each cell there is precalculated list of all items lying in it (whole or partially).
I did even write an email to galibert, but haven't got response :D.

Now I don't have much interest.
I have another idea about M68k core, but based on my experience of unfinished stuff...
I don't want to even describe it, because no reason to talk about it when nothing is done.

One of reasons why I've lost interest was overwhelming complexity.
I had idea to simulate scheme, but I haven't able to understand some simple parts of its work.
I don't want to even talk about physics aspects of simulation: solving differential equations, and etc.
I was really dissapointed when I realized that simulation code in one of tools wasn't working, it was just for some attempt to make it work.
Other reason was: after days of playing with it, I thought it's not worth it.

Good luck with this really hard work.
Image

ijor
Interested
Posts: 15
Joined: Fri Nov 16, 2018 11:46 am

Re: I'm officially building a microcode-level 68000 core

Post by ijor » Thu May 23, 2019 11:57 pm

Nemesis wrote:
Wed May 22, 2019 3:41 am
There are two kinds of annotations used in the top right of the nanoword content field in Appendix F. I've brought this data into the csv, but I don't know what it represents at this stage.
The "Access Label" field is supposed to be a combination of three different fields, the access class, mode and type. They don't exactly correspond to any field at the microcode. The two first ones, access class and mode are a nanocode thing. But they aren't really encoded at all, not specifically. The functionality is derived indirectly from other fields. Such as a transfer to the DOB register implies a write bus cycle. The Access Type is mostly a microcode thing, the FC field, but not exactly encoded as described either (see below).
The microinstruction at address "328", appearing in Appendix F on sheet A, row N, column 4, curiously has a blank label and origin. There are two defined instructions from Appendix A which are missing from Appendix F, which are "mmaw2" and "mmrw2"... Long story short, it appears this microinstruction was split
There are a few cases that a microinstruction is duplicated. Exactly same microword and exactly same nanoword content or origin. The duplication is sometimes needed because of the limitation of the microcode conditional branch.
The patents talk about this a fair bit as well. It talks about the 68-bit nanocode being expanded to "approximately" 180 "control points", and describes how IRD is used to key behaviour as well. Would it be an accurate statement to say though, putting exception handling to the side, that given an accurate IRD register state (and other registers of course) and the microcode/nanocode, all the data is present in one form or another to determine the actions that the processor would take when executing a microinstruction?
It is difficult to provide an exact answer because it depends on exactly what you really mean. But I would say that the microcode and the IRD PLA provides almost all the control logic not related to exceptions. Of course that the execution unit has quite some logic in itself (such as the priority encoder), it is not just a bunch of registers. There is the ALU as well, of course, that is only partially controlled by the microcode. There is the microcode conditional branch logic. There is the FTU that it is a real mess, what we would call spaghetti code. But arguably, the FTU only provides some constants, not exactly control signals. Timing control is not part of the microcode.
Could you expand on what some of those things are ijor? I haven't had a close look at what happens to the nanocode after decoding, so I'm not sure what's missing at this point from the patent docs. If you could highlight the information that's missing from the patents, or the information that's extraneous and not encoded (apart from the label of course), that'd be helpful.
I don't have an exhaustive list, but some things I remember:

- Patent sometimes qualifies the RX or RY fields specifying if it is a data or an address register (rxa/rya/rxd/ryd). This is not encoded at the microcode.
- Patent has a wildcard bus specification denoted with an asterisk. You could think that there is some kind of smart logic that would detect which bus is free and it would select it automatically. But there is no such a thing, always a specific bus is encoded.
- "The registers pointers" field in the microblock. Most of this is not encoded in the microcode.
- "Access type". The patent lists several types that aren't really encoded.

One of the problems when comparing the die with the patents, is that in many cases you don't know if the difference is due to a typo, a bug, or just a different implementation. E.g, the logic corresponding to the type field (db, dbi, dbc), what exactly each type performs, doesn't really match. I spend some time trying to determine what the patents really means and why it seems to be different to the die logic. I couldn't reach a definitive conclusion other that it doesn't really matter and I don't care too much. What matters is what it is actually at the die.
http://github.com/ijor/fx68k (68000 cycle accurate FPGA core)

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Mon May 27, 2019 4:58 pm

I was going to make my next big post on how microinstructions are addressed and encoded, but before that I decided it was important to start with a primer on understanding the CPU schematic diagrams. It's taken longer than I thought to write this part up, so I'm going to post it now and cover the 68000 microinstructions sometime in the next few days.

I've updated my Schematic Explorer with numerous bug fixes. I've also pushed an update to the schematic annotations, adding a lot of comments and annotations around the areas relating to microinstructions in particular, with some references back to the patent documents. Here's an overview of how it's looking right now:
Image
If you want to understand the things I'm talking about in detail, I'd strongly suggest downloading Schematic Explorer and the annotated schematic so you can view the areas I'm talking about and follow along.
You can download the latest Schematic Explorer build here: http://nemesis.exodusemulator.com/M6800 ... rerV1.4.7z (github)
And you can download the annotated schematic from the github repo here: https://github.com/RogerSanders/M68000Schematic


Interpreting die photos
In the questions/posts above, some basic coverage has been given on examining the raw die images and identifying transistors and connections on the die. I won't cover that in any more detail, and will instead focus on the schematic that Olivier has generated from the analysis of the die shots. While being able to refer back to the die shots is important in order to be able to double-check the schematic, tracing data flow and decoding logic from the die shots alone is much more difficult, and isn't practical to do for large regions. Generating a schematic is really a vital step in order to properly understand and document the internal workings of a device with this level of complexity. If you want to understand more about this essential first step of the process, review some of the posts prior to this one. The output from die shot analysis should be a series of masks representing each layer and the locations of vias connecting them (which can be generated from a vectorized image, as is the case with the analysis Olivier has done), from which a schematic can be generated through software analysis.


Interpreting the schematic
In order to follow what comes next, it's important to be able to understand the die schematic. There's really only one thing on the schematic we care about for the digital operation of the chip, and that's the MOSFETs and the connections between them. You may think a CPU is built from logic gates, and you may have heard that you can build any kind of logic circuit from a NAND gate. While that's true, gate structures like NAND gates don't exist as complete, discrete components on the die. These logic elements, as well as lots of other logic that doesn't fit the mold of traditional gates, are all built by a single underlying element, the MOSFET. MOSFET stands for "metal–oxide–semiconductor field-effect transistor", or "fet" for a shorter (technically not 100% equivalent) term. This is really the only kind of transistor that exists on the die surface. This is what we're measuring when we're counting transistors in a chip.

What is a MOSFET
I'm not going to fully discuss the design of a MOSFET, its variations of fabrication and usage, and so on here. There's more than enough written on the internet on this subject elsewhere which can be referred to if you want to know more. The Motorola 68000 being discussed here was fabricated using HMOS fabrication, which is a slight improvement over NMOS fabrication, and uses N-channel MOSFETs in both enhancement and depletion mode. Researching those terms will lead to more complete references on the subject. To understand the 68000 schematic, we simply need to understand that a MOSFET can serve two main roles:
1. As a digital switch
2. As a resistor
We'll cover both uses below.

A MOSFET as a digital switch
This is the most important function of the MOSFET in digital electronics. Here's a picture of a MOSFET operating as a switch
Image
In a nutshell, we have the "gate" terminal coming in at the top, with "source" on the left and "drain" on the right. If there's a voltage applied to the gate terminal (IE, logic level 1), then the switch is open, and the source and drain terminals conduct. Power can flow either direction through the source and drain terminals, for our purposes they're equivalent. No power flows from the gate to either the source or the drain, but having it sitting at a high logic level will connect the other two terminals together.

A MOSFET as a resistor
This is a MOSFET operating as a resistor:
Image
This is a depletion-mode MOSFET, which in the case of the 68000 (at least in this schematic) seem to operate in a permanently open state. The MOSFETs in this case, as I understand it, are purely there to provide some resistance (load) between a power source and the rest of the circuit. You will usually (always?) find these fets attached to the +5 volt rail, which is represented here by the bar connected to the left. With the switch permanently open, and the gate also tied to the output, this is basically tying all three connecting lines together, so what's the point of it? As I understand it, without some kind of resistance in the circuit, where there was a connection between +5v and GND, too much current would flow, causing significant power draw and heat generation. The MOSFETs here are simply to limit the current flow, and if this was an external circuit rather than an integrated one, resistors would probably take their place. Fabricating them out of MOSFETs on the die surface however is more efficient. For all intensive purposes however, when we're only interested in the digital operation of the chip, when we see one of these MOSFETs in the schematic we can just consider them to be a permanent connection between whatever's coming in on all three terminals.

Building gates from MOSFETs
Putting it together now, here's a look at how logic gates can be built. Here's a simple NOT gate:
Image
In this case, the line on the right is the input, and the line on the left is the output. The depletion-mode fet on the left is always open, so it will be pushing the logic level to high on the output line, unless the input line is high. In this case, the fet on the right will open, connecting the depletion-mode fet to gnd. Since the input current is limited by the depletion-mode fet, the line will be easily pulled to gnd, and since the gate of the depletion mode fet is tied to the output too, the output line will also be pulled low. Effectively anytime you create a connection to gnd, anything connected to that point, including through open fets, will be sucked down to logic level 0.

Let's take a look at something a bit more involved:
Image
Here we have a portion of the group 0 exception handling logic, with some classic gate structures identified. We have three inputs. The blue and purple lines coming in from the top and bottom and tied to the inputs at the central NOR gate signal when a bus error or an address error is being asserted, respectively. If either of these inputs are true, the central NOR gate will change state from 1 to 0. Note that if the two inputs were connected through two fets in series rather than in parallel, we'd have an AND condition here rather than an OR condition. Above this, the NOT gate will flip the result to drive the output leaving from the top center, effectively making that a simple OR result of whether an address or bus error is currently being asserted. At the lower right, we have another line coming in representing whether a reset, bus error, or address error exception is currently being processed. This is combined with the NOR output from the the section above as the inputs to another NOR gate. The output from this would be a 1 if there wasn't an address or bus error active, and there wasn't currently a reset, bus error, or address error exception being processed, or at least that would be the case, if the input coming in at the lower right was active high, but it's not, it's active low. As a result, the output will only be 1 if an address or bus error is raised while one of those listed exceptions is being executed. This is the logic that detects a double bus fault condition, as described in the 68000 Users Manual section 6.3.9.1.

If that sounds complicated, break it down to smaller pieces. A single fet is easy to understand by itself. If you can understand the signal that's driving it, you can look down at the effect it will have on the fets that it connects to, and so on. If you can't figure out what's an input vs an output line, pay attention to the gate terminals. Remember that the gate terminal on a fet can't pass any output current, it can only be fed an input, so anytime you come across a line being fed directly into a gate, as long as it's not the gate for a depletion-mode fet with a connection back to the gate, you know that line is being driven as an input.

Building Latches from MOSFETs
One more important aspect of the use of MOSFETs is how they can be combined to store data. A circuit to do that is called a flip-flop or a latch. Diving right in, here's a real example from the 68000 schematic:
Image
Here we have latches for two bits, in this case for bits 9 and 8 of the latched A1 microcode address. You should be able to see these two "cells" as mostly identical blocks forming most of this image. Leaving from the top center of each "cell" are the output lines from the bit latches, which are either high or low depending on what the currently stored value is in each latch. Coming in from the top down into the right side of each cell are the input data lines, which are used to feed a new value into the latch to store. Coming in from the bottom then across from the right we have a control line, which is asserted to open the latches and capture the current state of the input data lines. This control line has its logical NOT state computed to form a second control line, which will always be the opposite logic level of the other. These two control lines run to each cell.

Now looking at the operation, inside each cell there are two depletion-mode fets actively trying to drive the circuit. When the latch is open to capture the input state, the input line directly drives the gate of a fet in the bottom center of each cell, which will control whether the bottom depletion-mode fet is grounded or not. If that fet isn't grounded (IE, input is 0), it will ground the depletion mode fet above it, and it will ground the output line state too. If that fet is grounded (IE, input is 1), the fet above it will drive the output line to true. In both cases, the output of the middle depletion mode fet will also try and drive the ground state of the lower fet too, but it's currently disconnected from the gate by the control line state. Note that the depletion mode fet in the middle mirrors the logic state of the input line when the latch is open. When the latch is shut, the input line is disconnected, but at the same time the output state from the depletion mode fet in the middle, which was mirroring the input line state, is connected in its place. Since that fet was forced to mirror the logic state of the input line, when the lines switch over, it will take the place of the input line and hold the latch in the same condition continuously from that point forward, until the control signal switches again and feeds a new value on the input line.

Latches can be built in different ways, but this shows the concept and a specific case of latches being used in the 68000 processor. To recognize latches, look for logic blocks where two depletion-mode MOSFETs can control the ground state of each other.

Inverting and non-inverting superbuffers
A quick word about superbuffers. Superbuffers are (of course) build from MOSFETs, but unlike the logical elements described above, their purpose is more in the analog domain. If you have a single line that needs to drive the gate inputs to many fets, it needs to have a nice, strong power source. If you need to give a line a little more oomph, throwing in a superbuffer is a bit like an amplifier, boosting the signal (ehhh, maybe not really, but you get the idea). Superbuffers come in two primary forms, inverting and non-inverting. Here they both are:
Image
Inverting superbuffer

Image
Non-inverting superbuffer

Now note that as ijor pointed out in a previous post, the schematics are actually incorrect here. Both the fets tied to +5v here are the depletion-mode type, and the non-inverting superbuffer is a little more complex in the way its connected I believe, but for understanding the logical operation of the processor none of this is important. A non-inverting superbuffer, from a logical perspective, makes absolutely no difference to the circuit. Logic level high comes out as high, and low comes out as low. An inverting superbuffer does affect the result however, as it acts as a NOT gate, so high comes out as low and vice versa. Superbuffers are commonly used as drivers on reasonably sized PLA structures, which is a nice segway into the next section.

PLA Structures
PLAs make up a big part of the overall die space, most of it related to microinstructions, so you need to understand them. PLA stands for Programmable Logic Array, and you can read up on them separately if you want. To give a brief overview, I'm going to borrow (read: steal) a diagram on PLAs from the 68000 patent documents:
Image
This maybe isn't the best showcase of PLA design, but I had it on-hand. The arrows here show the direction of our theoretical "positive charge flow", with the traces marked in green showing where our charges are notionally flowing. The basic concept is simple: you feed a value in, and you get at least one value out. In this way it's just like an array, or lookup table if you will. The image above actually shows two separate values being returned from a single lookup. Some PLAs in the 68000 are like this, but basic PLAs are just map a single input value to a single corresponding output value. The nice thing about PLAs is that where you have redundant data, IE, two separate input values produce the same output value, it's often possible to shrink the size of the array logic and "key" that shared output value to respond to two (or more) inputs, if your input values are cleverly chosen.

Here's how the basic PLA works. Lets say you have a 3-bit input value, as shown in this example. You feed in those three separate lines, and their compliments (inverse/logical NOT) into the array, so for a 3-bit input we have 6 lines. Those lines drive our "rows" in the PLA (shown vertically here). Running perpendicular to the rows are our column lines. In the image, you should be able to recognise the presence of fets. In this case, the small circles present on some of the line intersections represent the presence of a fet. Where a fet is placed between a row and a column, with the row activating the gate on the fet, it ties the column line to ground. The columns are all fed with a +5v source. In a traditional well-formed PLA, one column line, and only one, will remain active for any given input. You place the fets to eliminate the columns that can't match based on the input line state, until only one remains, which selects the desired output value. Where you want a column to activate when a given input bit is set to false, you place a fet on the row that carries that input bit, so that it'll be ruled out if that bit is true. If you want a column to activate when an input bit is true, you place a fet on the compliment of that line, so that it'll be ruled out if it's false. If you don't care what the state of a given line is, you don't place a fet on either line. You can think of this as a combination of a matching value with a bitmask, or a target value with wildcards (IE, value 0b1100 mask 0b1110, or 110?, to match 0xC/0xD). Once the column is selected, it runs into another grid, this time as the row, where again +5v is driving all the column lines. The column lines here represent your output data. At this point, you simply place fets on the column to ground the column the bits you want to set to 0 for each entry in your table, and leave the ones you want set to 1 to pass straight through.


I'm going to leave things there for tonight. I think this is enough of a primer on the schematic itself. Next big post will cover microinstruction addressing and decoding.

User avatar
Nemesis
Very interested
Posts: 756
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: I'm officially building a microcode-level 68000 core

Post by Nemesis » Tue May 28, 2019 12:18 am

I managed to track down a pdf of that "Microarchitecture of VLSI Computers" book that ijor mentioned. It has a lot of VERY interesting material on the 68000, much of which I haven't seen anywhere else. This book is a trade journal of sorts, being a compilation of papers presented at the "NATO Advanced Study Institute on Microarchitecture of VLSI Computers" in Italy on July 1984. Here's the link:
https://mega.nz/#!FQFiUawI!gF5okEJ7vd-1 ... LGiJnh5GPY
Starting on page 225 is a very detailed paper on various internal aspects of the 68000 design, and a thorough coverage of the test mode feature. Also of interest is the paper describing the Micro/370 processor starting on page 12. If you look at the documents, it might look a bit... familiar. It seems this processor leans heavily on the design of the 68000. Not surprising, at it appears "Nick Tredennick" was the lead designer of the 68000 for Motorola, and then the "Micro/370" after his apparent defection to IBM. He developed "The Flowchart Method" for VLSI processor design which is the origin of those microword design "sheets" I transcribed from the patents. These articles make for an interesting read. The references are gold too. With a few of these article and author names, it becomes easy to start cross-referencing other detailed publications by the relevant people involved.

EDIT: Here's an article from Nick Tredennick explaining his flowchart design method, which can help put more things in context:
https://mega.nz/#!hNkTyAQT!9LbDJS-VawCk ... soO2ozfcCc

ijor
Interested
Posts: 15
Joined: Fri Nov 16, 2018 11:46 am

Re: I'm officially building a microcode-level 68000 core

Post by ijor » Wed Jun 05, 2019 9:04 pm

Nemesis wrote:
Tue May 28, 2019 12:18 am
Not surprising, at it appears "Nick Tredennick" was the lead designer of the 68000 for Motorola
Just for the record, Nick Tredennick wasn't exactly the lead designer. Tredennick designed the microcode and parts of the logic. The main architect and project manager was Tom Gunter.
http://github.com/ijor/fx68k (68000 cycle accurate FPGA core)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests