m68k smoketest waveform

MC68000 softcore smoke test

I have 5 articles waiting to finish and publish, most of them are touching theoretcal approach of the Nexi microcomputer. But I am too impatient, I want to run something! I have decided to make a smoke test of my chosen m68k. This is a starting point, most of the work will be a development of this simple test.

Couple of weeks took me to run m68k core for the first time. I have decided to use ao68000 core by Aleksander Osman. It is written in verilog with Wishbone b.3 interface (written as separate module, so it would be quite easy to change it to original m68k interface), finished (most projects aren’t fully functional). Disadvantages are not exact timing of instruction (I don’t care) and usage of wishbone bus (I’m not planning to make any application with physical IC, so, also, I don’t care).

AO68000 was using ram Altera’s megafunction as a storage for microcode and A and D registers, so it was impossible to run it on simulation. I have rewritten this piece of code with standard RAM implementation. With success!

Next, I have written simple testbench, to connect ao68k with wishbone based RAM module.  The catch was with address lines connection. AO68k is using wishbone’s SEL bus, which indicates what part of dat_o signals are expected to have valid data. For example, if microprocessor want’s to read 1 byte of data it changes the state of sel[3:0] to 0b0001. If microprocessor want’s to read whole 32 bits of data it changes the state of sel[3:0] to 0b1111. AO68000 have 32 bit address bus, 32 bit data bus and 8bit granularity.

Because of the fact, my ram module’s size is determined by address bus width, and I wan’t to have 1M of RAM, I have defined 32 bit adddress wire, connect [32:2] lines with ao68k, and [19:0] to ram module, assigning the 2 least significant bits with zeroes.

Next step was to create a memory dump with valid exception table and code. M68000 expects to have Exception table at the beggining of the memory address space.

The code is pretty straightforward. M68000 requires to have exception vector table at offset 0x0. This is a major issue when designing your board, because it also requires to have RAM memory starting at 0x0, which is uninitialized after a reset. M68010 has Vector Base Register. It’s value is added to the offset of exception to compute the absolute address of exception function. At reset time, the value to VBR is 0x0, so you also have to have initial exception table at 0x0. But we don’t have to worry about that now. First two entries have 32 bit, where all other have 16 bit entries. Not all entres all included.

The actual code starts at 0x100. We make some random moves, then loop again to the label at 0x100. Nothing more. This piece of code helps me to investigate m68k assembly, by playing with it, and watching, how it is behaving in gtkwave.

Compilation is a bit tricky. I use m68k-unknown-elf compiler, created with crosstool-ng. raw2vnem.py is a script that converts 32-bit hex input into vmem output, for reading by readmemh.

Let’s see how does disassembled code look like. As you can see, rasm2 is using U2 encoding instead on unsigned one.

The final step is to run it all, and analyse the waveform. Seems like everything is working fine, the code forces the cpu to jump from 0x0000011c up to 0x00000100. The additional 0x0000011e and 0x00000120 is probably caused by prefetcher. The code is available at nexi github repository.

m68k smoketest waveform
gtkwave print screen

What’s next?

My current (not organized) todo list contains:

  • create high level design of the project
  • analysis of ao68000 internals
  • rewrite its microcode generator
  • create/obtain table of differencies between 68000, 68010 and so on
  • first draft of cache module
  • run above code with added uart ip core in some FPGA devboard. Then, write bootloader for it.
  • toolchain research (crosstool’s gcc, llvm + clang, ready-to-use toolchains etc)
  • run ucLinux on the core

Leave a Reply

Your email address will not be published. Required fields are marked *