Close

CAT Board SDRAM Test

A project log for CAT Board

The CAT Board is part of a Raspberry Pi-based hand-held FPGA programming system.

dave-vandenboutDave Vandenbout 02/25/2016 at 19:021 Comment

It's been a while. I got the SDRAM on the CAT Board working a few weeks back, so I'll use this post to document that.

I've been using SDRAMs with FPGAs since 2001. Back then, I created an SDRAM controller module in VHDL that manages all the SDRAM timing, bank and row activation, address multiplexing and refreshing while presenting an interface that looks like a static RAM to the rest of the FPGA.

To test an SDRAM, I attach the controller to a finite state machine (FSM) that sequences through a two-phase process:

  1. Write the entire SDRAM with a pseudo-random sequence from a random number generator (RNG).
  2. Reinitialize the RNG with the same seed and then compare its output to the values read from the SDRAM. If the outputs from the RNG and SDRAM match over the entire address range, then the test is passed.

Since I've switched to using MyHDL for the CAT Board, I needed to convert the SDRAM controller. That's a big job. Luckily, I mentored a student for the 2015 Google Summer of Code (GSOC) and he translated the controller to MyHDL. He also provided a simulation model of the SDRAM chip.

Converting my RNG into MyHDL should have been a much simpler task. At least, it would have been if I was the kind of guy that didn't go to extremes. As it was, I created a Jupyter notebook that simulates several versions of RNGs with MyHDL and visualizes the probability distributions they output. All that to end up with a standard LFSR-based RNG.

I combined the MyHDL modules for the SDRAM, SDRAM controller, RNG and FSM and simulated the entire test process. The simulation found a small bug in the SDRAM controller that was the cause of a failure in one of the GSOC tests during the summer. (So *that's* what caused it!)

Once the simulation was working, I tried to map it to the FPGA on the CAT Board. Unfortunately, the SDRAM controller describes its I/O using interfaces instead of lists of signals. Interfaces are a (relatively) new MyHDL feature that simplifies the interconnection of modules and reduce errors (that's good!), but using them with pin assignments is undocumented (that's bad!). So I had no way to assign the individual I/O signals to the FPGA pins connected to the SDRAM on the CAT Board.

I finally resorted to exporting a Verilog version of my design using the MyHDL conversion routines. Using the port definitions in the converted Verilog code, I made the appropriate pin assignments for the CAT Board within Lattice's iCEcube2 software. Then I compiled the Verilog using the iCE40HX8K FPGA as the target device. I took the bitstream generated by iCEcube2 and transferred it to my Raspberry Pi.

From there, it was just a matter of having the RPi download the bitstream to the FPGA on the CAT Board and running the SDRAM test. Here's what happened:

So the SDRAM works! That was actually a little easier than any of my previous tests.

Discussions

andrea venturi wrote 03/08/2016 at 21:23 point

it's great to see you are back at it. i'm dying to commit for one board on a production run.

this iCE40 + SDRAM design seems pretty unique actually!

  Are you sure? yes | no