Project Logs

Collapse

• Mainline Linux 7.1 on a Motorola 68008 - The Slowest Still-Supported CPU?

  Colin Maykish • 06/07/2026 at 22:35 • 1 comment

  Mackerel-08 now boots the mainline Linux kernel! That's v7.1-rc6 at the time of writing. An 8 MHz-rated Motorola 68008 (here running at 14 MHz) and 3.5 MB of RAM are enough to boot the latest kernel into userspace and provide a minimal BusyBox shell. That's about all it can do. My attempts to add more kernel features quickly blow up the memory budget and the board runs out of RAM before it finishes booting, but it does technically run!

  In my estimation, this has to be one of the slowest real computers with full modern kernel support. If you know of one even more limited, I would legitimately love to hear about it. It's still amazing to me how versatile Linux is. This 40+ year-old cost-reduced CPU was not a powerhouse even in its day (the 68010 came out the same year), yet it boots the same kernel as my new Ryzen desktop.

  Mackerel-08 and Mackerel-10 have shared a functional uClinux port for some time now, but it was based on a decade-old release tarball I found online and used kernel v4.4. This actually worked out alright. There's honestly not a huge difference between v4.x and v7.x specific to the m68k architecture, but it was tied to an old prebuilt toolchain that I couldn't reproduce locally and it made adding new modern code to the project much harder - gcc 5.4 doesn't always want to compile the latest application code.

  Recently, I was able to boot v6.17 on Mackerel-30, but that system has a real MMU and comparatively a ton of RAM at 128 MB. I actually started with the goal of getting the 68010 with its NOMMU config running the same version as the 68030 and eventually settled on the latest release candidate, v7.1-rc6. I didn't really consider that the 68008 would be feasible with a decade of kernel bloat and its anemic memory budget. When the 68010 port went relatively smoothly, I set up a similar config for the 68008 and off I went: Step 1, remove everything from the kernel config you think you can live without. Step 2, keep removing stuff... Eventually, with a tiny ROMfs baked into the kernel image and all code executing in place (not copying into RAM first), Mackerel-08 managed to boot into BusyBox with a few hundred KB of RAM to spare.

  I now have the same kernel, with only per-board defconfigs and a few #ifdefs, booting and running on all three Mackerel boards.

• Drivers, Drivers, Drivers!

  Colin Maykish • 05/31/2026 at 21:58 • 0 comments

  Mackerel-30 is actually shaping up to be a real Linux machine! I've spent a bunch of time recently building out drivers for all the hardware on the board. It now has persistent storage, a fully implemented serial port, and even networking. I'm pleased that none of the minor design problems with the first prototype PCB have prevented any of this work. Despite the shortcomings, Mackerel-30 (as well as my understanding of Linux kernel development) is progressing really well.

  IDE

  Mackerel-10 has a functional IDE driver in uClinux, but it's pretty bare bones and built on the older Linux kernel driver API. With Mackerel-30, I was able to implement the IDE interface on top of the more modern libata framework. The idea is still the same - tell the kernel about the memory-mapped registers and setup the proper interrupt lines. The lovely thing about Linux is that once you have the foundational layer working, you get all of the things above it for free. One IDE driver gets you block devices, filesystems, fdisk and other tools without any additional code.

  Speaking of IDE, I made a few tweaks to the bootloader IDE/FAT code that reduced the load time of the kernel image from 20 seconds to about 17. That's fine, but hardly noticeable in practice. The massive gains came from enabling the 68030's instruction cache before starting the IDE load command. This change alone dropped the time under 5 seconds for a 5MB kernel file. That's over 1 MB/s! Doing the math, there's still some performance on the table, but I don't think it's really worth the time to rewrite the IDE code in assembly.

  PPP

  I took a short detour to set up what turned out to be a terrible first network connection for Mackerel-30. PPP is a point-to-point protocol for handling network traffic over a simple serial port. I patched up the XR68C681 driver to handle the second port on the DUART and implement proper baud selection logic. With that in place, there's a config in the kernel to enable the protocol and then a simple cross-compile of the pppd binary itself.

  The second serial port (/dev/ttyXR1) is connected to my Linux PC, pppd is started on both ends. Tada! Network connection...

  ~ # pppd /dev/ttyXR1 9600 noauth local nodetach 10.0.0.2:10.0.0.1 &
  Using interface ppp0
  Connect: ppp0 <--> /dev/ttyXR1
  local  IP address 10.0.0.2
  remote IP address 10.0.0.1
  ~ # ping 10.0.0.1
  PING 10.0.0.1 (10.0.0.1): 56 data bytes
  64 bytes from 10.0.0.1: seq=0 ttl=64 time=210.000 ms
  64 bytes from 10.0.0.1: seq=1 ttl=64 time=210.000 ms

  This is extremely limited out of the box. The host PC and the Mackerel board can both ping eachother, but that's about it, not to mention the baud rate limit. I was only able to get the connection stable at 9600 bps.

  It's also possible to set up routing, iptables, and DNS and I did actually get Mackerel pinging the external internet, but this whole exercise was more of a proof-of-concept of the Linux networking stack on Mackerel than a practical result. Still fun to see though!

  SPI + ENC28J60 Networking

  And now for the fun one... There are so many peripherals that communicate over SPI. Having that interface available on the board opens up a world of options for connectivity, storage, sensors, etc.

  The only problem is that nothing on Mackerel-30 actually speaks SPI right now. Fortunately, Linux has a really solid bitbang SPI controller that can be easily implemented on top of just about any GPIO. I wired up the SPI code to the DUART I/O registers and, as with the IDE driver, every layer above it just falls into place.

  The cheap ENC28J60-based ethernet breakout board I have requires only a SPI connection plus a single interrupt line. There's a driver already available in the Linux kernel and it's one config option away.

  ~ # uname -a
  Linux mackerel 6.17.1-multi-00028-g5b42c9f55f18-dirty #1 Mon May 25 11:28:54 EDT 2026 m68k GNU/Linux
  ~ # ping -c 4 google.com
  PING google.com (142.250.65.78): 56 data...

  Read more »

• Discord Server Is Up

  Colin Maykish • 05/23/2026 at 19:26 • 0 comments

  For whatever reason, I've seen a recent increase in interest for the Mackerel-68k project. This is great! I'm very happy that folks are enjoying the project, building boards, and running code.

  Since questions and comments are coming in from all over the place, I think it makes sense to centralize them.

  With this in mind, I've set up a dedicated Discord server:

  https://discord.gg/DtvXxYCt2Q

  If you need help with hardware bring-up, want to show off your build, or just want to talk about the project, please come by.

  Please keep in mind, this is a hobby project. I work on it in my spare time. I am happy to help out, but set your expectations accordingly.

• Linux 6.17 On Mackerel-30

  Colin Maykish • 10/17/2025 at 05:16 • 2 comments

  After a long battle with toolchains, head.S, and a serial driver, Mackerel-30 now boots Linux kernel 6.17 (the latest release at the time of writing) and hands control over to an interactive Toybox shell. A minimal system for sure, but a fully functional, standalone, and modern Linux installation on an almost 40 year-old CPU. I'm feeling pretty good about this accomplishment. Here's a rough outline of how I got here.

  The first hurdle is setting up a toolchain. Unlike with Mackerel-08 and Mackerel-10, I didn't have the advantage of a complete build system with precompiled toolchain like the one provided by uClinux. Every piece had to be put together manually. I settled on using crosstools-ng to assist in the toolchain setup. Like the Linux kernel itself, crosstools-ng still supports the m68k architecture. It took a lot of trial and error (and many objdumps), but I settled on a toolchain consisting of gcc 15, binutils 2.45, and musl as the C library. The most painful part of this step was figuring out the right combination of crosstools config settings and CFLAGs to get a binary that contained only 68030-supported instructions and no FPU instructions (my FPU is still disabled).

  With a functioning toolchain, I could compile the kernel. I started working my way through early kernel boot code, methodically placing putc calls all over the head.S assembly file. I spent what felt like too much time trying to coerce Linux to work with my memory map until I gave up and adjusted the address decoding on the CPLD to align with the Linux m68k expectations, removing the SRAM chip entirely and remapping the 128 MB of DRAM to 0x00000000-0x7FFFFFFF. The MMU was set up to pass these physical addresses to the same virtual addresses. Mackerel-30 had finally reached start_kernel().

  Optimistically, the hard part was now over - the kernel was booting and I had output coming through the early console. I had to write a proper serial driver for the XR68C681 DUART, move the timer interrupt duty to the CPLD, and debug a few minor issues, but before too long, Mackerel-30 was making the jump to userspace. This event was anticlimactic as there wasn't one.

  There are a million options when it comes to building a userspace and it's where a lot of the fun of building a Linux system happens. With a modern kernel, MMU support, and working console I/O, the possibilities are endless, but it's best to start simple. I chose a barebones root filesystem populated almost exclusively by a single Toybox binary and a few symlinks. Toybox can act as the init system as well as the interactive shell with a handful of useful commands. I used cpio to pack this barebones filesystem into an initramfs and bundled it with the kernel image. Mackerel-30 is now a complete Linux system:
  

  $ hostname
  mackerel
  $ uname -a
  Linux mackerel 6.17.1-multi-00013-g4a905c110481-dirty #5 Thu Oct 16 18:39:30 EDT 2025 m68k Toybox
  $ cat /proc/cpuinfo
  CPU: 68030
  MMU: 68030
  FPU: none(soft float)
  Clocking: 8.1MHz
  BogoMips: 2.04
  Calibration: 10240 loops
  $ free -h
       total used free shared buffers
  Mem: 123M 4.1M 119M 736K 0
  -/+ buffers/cache: 4.1M 119M
  Swap: 0 0 0
  $ mount
  rootfs on / type rootfs (rw,size=62652k,nr_inodes=15663)
  devtmpfs on /dev type devtmpfs (rw,relatime,size=62652k,nr_inodes=15663,mode=755)
  proc on /proc type proc (rw,relatime)
  sysfs on /sys type sysfs (rw,relatime)

  Next up is a lot of cleanup. There were definite corners cut in the bring-up process and now is a good time to revisit some of the dirtier hacks before I forget everything and move on.

  On the top of the todo list is an IDE driver. I implemented a crude PIO-based driver on Mackerel-10 and that's working well enough, but it relies on an older driver interface. I think there are more modern examples to explore on Mackerel-30. Either way, permanent storage unlocks a lot of functionality and gives me the option to boot from a real drive instead of a temporary RAM-based filesystem.

  I'd also like to finish bringing up the...

  Read more »

• 128MB Ought To Be Enough For Anybody

  Colin Maykish • 01/04/2025 at 17:59 • 4 comments

  I was a bit premature in declaring the DRAM controller for Mackerel-30 complete. It was minimally functional as an 8-bit wide memory, but failed for any multi-byte or offset bus cycles. Implementing these wider memory cycles correctly requires some additional logic in the controller to correctly select the CAS lines for all possible bus cycle types.
  

  On 72-pin SIMMs, there are four RAS lines and four CAS lines. Asserting a pair of RAS lines (0,2 or 1,3) selects between the two "sides" of the SIMM in the case of double-sided SIMMs (Note: these sides refer to how the DRAM chips are wired electrically, not necessarily how they are physically soldered to the PCB). Each of the CAS lines acts like a byte-select pin for the four bytes in the 32-bit wide SIMM. The trick to getting the correct bytes from DRAM onto the data bus requires decoding the SIZ0, SIZ1, A0, and A1 pins from the CPU into the right combination of CAS signals for the SIMM.

  Fortunately, the MC68030 datasheet covers all of this in detail.

  These two tables show how the SIZ0 and SIZ1 pins can be used to determine the requested bus width and how the A0 and A1 pins are used to set an offset if the request is not long word-aligned.

  This huge table displays all possible combinations of bus width and offset and shows where the data is expected to be in each case. Since the DRAM always acts as a 32-bit wide memory, each of the entries in the Long-Word Port column map to a combination of CAS lines. For example, if the CPU requests a 16-bit word with an offset of 1 (row 6), the second and third bytes of the DRAM need to be read, so the CAS pattern is 0110 (active high).

  The easiest way to translate this information into Verilog for the DRAM controller is with a case statement:
  

  wire [3:0] CYCLE_TYPE = {SIZ1, SIZ0, ADDR[1], ADDR[0]};
  reg [3:0] CAS;    // active high
  
  always @(*) begin
      case (CYCLE_TYPE)
          // CYCLE TYPE <= CAS[3:0]
  
          // byte
          4'b0100: CAS <= 4'b1000;
          4'b0101: CAS <= 4'b0100;
          4'b0110: CAS <= 4'b0010;
          4'b0111: CAS <= 4'b0001;
  
          // word
          4'b1000: CAS <= 4'b1100;
          4'b1001: CAS <= 4'b0110;
          4'b1010: CAS <= 4'b0011;
          4'b1011: CAS <= 4'b0001;
  
          // 3-byte
          4'b1100: CAS <= 4'b1110;
          4'b1101: CAS <= 4'b0111;
          4'b1110: CAS <= 4'b0011;
          4'b1111: CAS <= 4'b0001;
  
          // long word
          4'b0000: CAS <= 4'b1111;
          4'b0001: CAS <= 4'b0111;
          4'b0010: CAS <= 4'b0011;
          4'b0011: CAS <= 4'b0001;
  
          default: CAS <= 4'b1111;
      endcase
  end
  

  One issue I ran into while putting this solution together was strange RAS behavior. Each pair of RAS lines is supposed to act as a bank selector, but when I implemented this, I lost access to half the bytes in the memory. It turns out I mislabeled the RAS pins on the SIMM slot in my schematic and had RAS1 and RAS2 swapped. Fortunately, this is all semantics and swapping RAS1 and RAS2 in the CPLD pin mapping solved this problem entirely.

  
  

  With the DRAM now handling different cycle types correctly, I set up address decoding to handle 64 or 128 MB SIMMs. The SIMM bank is selected based on the A26 line. If A26 is 0, RAS0 and RAS2 will be asserted, if A26 is 1, RAS1 and RAS3 will be asserted instead. This allows support for either a 64 or 128 MB SIMM, only the addressable size of the DRAM will change: 0x4000000 or 0x8000000 respectively. Smaller single-sided SIMMs (4 and 16 MB) should also work without modification, but other sizes of double-sided SIMMs would require modification to this address decoding scheme to be fully mapped, but who doesn't want as much RAM as possible anyway!?

  To wrap up this DRAM improvement, I revamped the memory test code in the bootloader. There are now two ways to test memory: a simple 8-bit read and write test and a new 32-bit test that can cover the entire 128 MB memory space. The 32-bit...

  Read more »

• More Mackerel-30 Bringup Progress

  Colin Maykish • 12/15/2024 at 00:27 • 0 comments

  Mackerel-30 board bringup is going well for the most part. I've got the IDE interface and DRAM controller hooked up and functional. I did make a mistake in IDE wiring though. One of the buffer chips between the IDE interface and the CPU data bus has the bits wired in reverse order, i.e. bits 0-7 are mapped to 7-0. Fortunately, the rest of the control circuitry is wired correctly and the bits can be reversed in software for now. This adds a bit of overhead, but Mackerel-30 is not winning any speed contests right now anyway. I'll add it to the list of fixes for the next PCB revision.

  I also ported over my DRAM controller from Mackerel-10. Going from four 30-pin SIMMs to a single 72-pin SIMM required a bit of adjustment to the CAS and RAS logic, but the state machine and refresh timing is almost unchanged. Unfortunately when I bought DRAM sticks for this project, I didn't notice that the 64 MB modules I ordered were 3.3v only. I've ordered some more 32 MB and 64 MB modules that will work at 5v, but for now I'm using a backup 8 MB stick.

  There seems to be some inconsistencies with how 72-pin SIMMs have their RAS and CAS lines wired up to the individual DRAM ICs. The 8 MB sticks I have seem to map one RAS line to each of the 4 8-bit DRAM ICs on the stick, but based on other datasheets and information I've seen online, this may not be 100% standardized. My interpretation is that normally the four RAS pins operate in two pairs of two, effectively acting as a bank switch for double-sided modules. I'll have to experiment when I receive the new batch of SIMMs, but in the worst case, I can make some minor adjustments to the DRAM controller logic to compensate. I'm feeling pretty confident in the core functionality of the controller at this point.

  My intention was to finish out this update with a proof-of-concept FPU test, but I realized the libc library I'm using doesn't support floating point at all. I could still add the new decoding logic to the CPLD and do some tests in assembly, but I think I will wait on the FPU for now. I've got the hardware far enough along to start porting Linux to Mackerel-30 and I'm much more excited to get started on that than to worry about the FPU at the moment.

• Mackerel-10 Nearing Completion

  Colin Maykish • 12/12/2024 at 16:12 • 0 comments

  I've put together a new revision of the Mackerel-10 PCB to fix the issues in v1.0. The main problems with v1.0 were in the IDE interface. I had the direction of the buffers reversed which required a cut trace and a bodge to fix. I also failed to connect the second IDE chip-select pin to the CPLD, so that had to be bodged in as well to enable control of the IDE interrupts. With the circuit corrected, the IDE interface is working as expected without any bodges.

  There are actually two very similar versions of the revised PCB. Originally I created v1.1 which fixes the issues listed above. After experimenting with the DS1233 reset circuit on Mackerel-30, I decided to add it to Mackerel-10 as well, replacing the 555 circuit that was doing the job previously. This version is v1.2 and is identical to v1.1 other than the reset circuit. If you would like to build one of these boards, I'd recommend v1.2, but v1.1 is still an option if you'd prefer to use the 555 reset.

  As discussed in a previous post, the DRAM controller is running at 50 MHz with good stability. It is also decoupled from the CPU clock. My 68010s start to have issues with even a slight overclock, but the system runs well with the CPU clock at the rated maximum of 10 MHz. Using the 68SEC000, I'm able to run at 20 MHz. The SEC chip is capable of much more, but the DUART and IDE interfaces start to behave erratically beyond that point. It's possible that some additional wait-state logic would remove this bottleneck.

  Finally, I've made some progress on the software side as well. The bootloader now supports the FAT16 filesystem and can load the Linux image from a file on the IDE drive instead of reading raw sectors into memory. I've set up the SD card with a small FAT16 partition containing the kernel image file and a larger ext2 partition. The ext2 partition can be mounted from uClinux and gives Mackerel-10 an option for writable persistent storage.

  At this point, I don't have any immediate plans for more hardware changes to Mackerel-10. The current PCB satisfies all of the requirements I had for this system when I started. My focus has shifted to Mackerel-30, but there are still some interesting software options to explore on Mackerel-10.

  Mackerel-10 Release Files: https://github.com/crmaykish/mackerel-68k/tree/master/releases/mackerel-10

• 68030 Is Executing Code!

  Colin Maykish • 11/25/2024 at 18:17 • 0 comments

  The first prototype of Mackerel-30 is alive! After many hours of soldering, updating Verilog, and modifying memory maps and Makefiles, the 68030 is up and running. Better yet, it's running the same bootloader code as Mackerel-08 and -10 and loading programs over serial. Since the 68030 is more or less a superset of the earlier CPUs, very little C code needs to change from previous iterations of Mackerel.

  So far I have verified the basics of the system. Only the ROM, SRAM, and DUART have been tested, but there's enough glue logic implemented to run the bootloader and handle vectored interrupts from the DUART.

  Seeing a new design come to life really never gets old. That said, this is a prototype and there are already some problems. For one, the serial header is backwards from previous Mackerel hardware. This caused a slight panic when the code appeared to be running, but no serial output was displayed. Fortunately, flipping the USB-serial adapter solved that issue.

  I also managed to export the Gerbers without noticing that the VIN pin of the 3.3v regulator was not connected to anything. I need to figure out why KiCAD didn't complain about this, but the 3.3v power is not actually needed for the board to run, it's just there for external hardware, so no harm done. It's also easy enough to bodge the VIN pin to a nearby 5v rail if necessary.

  I haven't hooked up the FPU yet, but I am missing A13-A15 pins on the glue CPLD. I think these are required as part of address decoding for the FPU, so they may need to be bodged in.
  

  Finally, there are a few footprint issues. The mounting holes for the 72-pin SIMM are not all sized correctly, requiring some "plastic surgery" to solder in the socket.

  The DIN 41612 connector footprint also has issues. The holes are all way too small to fit the pins of the connectors I have. This is not a custom footprint, it was pulled from the KiCAD library, so it's possible I just have non-standard connectors, but either way, it makes the expansion header pretty unusable.

  With the basics working, my plan is to finish assembly and test the DRAM, IDE, and FPU. If at least the DRAM and IDE are functional, I should be able to start on the Linux port. If I find any showstopping issues, I guess Linux will have wait for the next revision.
  

• What's New For Mackerel-30?

  Colin Maykish • 11/10/2024 at 02:02 • 0 comments

  Rather than design a bare minimum prototype for Mackerel-30, I decided to take a bit more risk and incorporate most of features I want from the start. Moving from the 68008 to the 68010 was a reasonable step up in complexity. Jumping to the 68030 presents another significant leap with 32-bit buses and more complicated control logic. In some ways, it's actually easier to deal with though. The dynamic bus sizing removes the requirement for 16-bit ROM and RAM chips. A single 8-bit ROM and SRAM should be enough to bootstrap the system.

  Besides the new CPU, I've included a few other hardware upgrades. I'm looking forward to getting the MC68882 FPU up and running. It should be supported by Linux and might give a boost in performance for things like scripting languages or graphics support if and when I get to those.

  I've also upgraded to 72-pin SIMMs for the DRAM. Each SIMM is 32-bits wide which makes the wiring straightforward and requires only a single module. The available capacities are also quite a bit higher than 30-pin modules, going up to at least 128MB. The DRAM controller will be adapted from the one I designed for Mackerel-10.

  The only piece I have not included in this first prototype is networking hardware. I'm still exploring some options in this area and I'm not ready to commit to one design. Once the base system is brought up, I plan to build a network card to connect to the expansion header.

• Another Word On DRAM

  Colin Maykish • 10/25/2024 at 04:15 • 0 comments

  Getting a DRAM controller working at all feels like a great accomplishment, and while it has been stable and functional, there were some situations I couldn't explain. For example, it was not possible to run the DRAM controller at anything other than twice the CPU speed, even running them at the same frequency failed completely. I was not satisfied with my understanding of my own design. I also wanted the option to run the DRAM on its own independent clock to completely free up the choice of oscillator for the CPU.

  With the goal of better understanding and more flexibility, I took the lessons learned from my first iteration and went back to the drawing board, starting with the datasheet. The simplest place to start is the CAS-before-RAS refresh.

  CAS-before-RAS Refresh

  The refresh process is not complicated: pull CAS low, then pull RAS low, raise CAS, and then raise RAS again. One thing worth noting here is that the WE pin has to be HIGH by the time RAS is lowered. Since the state of the WE pin is "don't care" for the rest of the refresh cycle, I chose to pull it HIGH in the first state of the refresh state machine. Note: Mackerel-10 has four 30-pin SIMMs in two 16-bit pairs, A and B. RAS is shared between SIMMs in a pair, but the CAS lines are all independent, thus two RAS pins and four CAS pins in my controller.

  REFRESH1: begin
      // Acknowledge the refresh request
      refresh_ack <= 1'b1;
  
      // Lower CAS
      CASA0 <= 1'b0;
      CASA1 <= 1'b0;
      CASB0 <= 1'b0;
      CASB1 <= 1'b0;
      WRA <= 1'b1;
      WRB <= 1'b1;
      state <= REFRESH2;
  end
  
  REFRESH2: begin
      // Lower RAS
      RASA <= 1'b0;
      RASB <= 1'b0;
      state <= REFRESH3;
  end
  
  REFRESH3: begin
      // Raise CAS
      CASA0 <= 1'b1;
      CASA1 <= 1'b1;
      CASB0 <= 1'b1;
      CASB1 <= 1'b1;
      state <= REFRESH4;
  end
  
  REFRESH4: begin
      // Raise RAS
      RASA <= 1'b1;
      RASB <= 1'b1;
      state <= PRECHARGE;
  end

  The final piece of the DRAM refresh cycle is determining how often it needs to happen. According to the datasheet, all 2048 rows need to be refreshed every 32 ms. If we refresh each cell incrementally with CBR, that means we need to refresh a cell every 32 ms / 2048 = 0.015625 ms. That equates to 64 kHz. Finally, the DRAM controller is running from a 50 MHz oscillator, so 50 MHz / 64 kHz = 781 cycles between refreshes.

  The Verilog for counting cycles is basic, but I'll include it here for reference. The two refresh_ registers are used to pass the refresh state back and forth between this generator code and the main state machine. REFRESH_CYCLE_CNT is set to 781.

  // ==== Periodic refresh generator
  reg refresh_request = 1'b0;
  reg refresh_ack = 1'b0;
  reg [11:0] cycle_count = 12'b0;
  
  always @(posedge CLK_ALT) begin
      if (~RST) cycle_count <= 12'b0;
      else begin
          cycle_count <= cycle_count + 12'b1;
  
          if (cycle_count == REFRESH_CYCLE_CNT) begin
              refresh_request <= 1'b1;
              cycle_count <= 12'b0;
          end
          
          if (refresh_ack) refresh_request <= 1'b0;
      end
  end

  Read/Write Cycles

  With the CBR refresh behavior confirmed, I started to revamp the rest of the state machine, i.e. the process of actually reading and writing memory. As mentioned, my first implementation worked, but just barely. One of the issues I had was a dozen or more compiler warnings in Quartus that looked something like this: Warning (163076): Macrocell buffer inserted after node. I could not track down an exact cause, but the little information I found online and my own testing seemed to indicate that this error basically means "you're trying to do much work at once". By breaking up my state machine into more smaller states and removing highly parallel pieces of code, I was able to get rid of all all these warnings. It seems like the key is not to change too many register values per clock cycle, but to instead pipeline the design.

  The actual logic of the DRAM read and write...

  Read more »

View all 36 project logs