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: 748
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: 748
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 173 times

ijor
Interested
Posts: 12
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: 748
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: 748
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: 12
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)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest