Using SDRAM in FPGA Designs | Hacker News Reader

Using SDRAM in FPGA Designs

joshbassett.info

127 pointsnullobject25 comments

Thank you for releasing this! Last time I needed an SDRAM controller, I had trouble finding anything that was open source, readable, under a permissive license, and published on GitHub. I ended up using this one by Matthew Hagerty in 2014: http://codehackcreate.com/archives/444

The notes on getting the clocking right are also very much appreciated; that's always tricky with SDRAM.

You could write one for yourself in no time as long it isn’t DDR type. Most applications use only one access type (16 burst for example) anyway, so you don’t need to implement all bells and whistles found in data sheet.

This is very interesting and well put together. The diagrams are great. Very easy to read and understand as a software developer that rarely interacts with such low level things. Likely because you're also a software developer :)

I'm curious about introducing a phase shifted clock with a PLL in order to get the rise/fall timings correct. Is that standard in other controller implementations? Is that technique something that's used in other, similar situations? It sounds like a pretty generic and simple way to solve timing issues of that nature. I guess I'm mostly wondering how you came up with that solution and if there are any alternatives? The minds of EE people intrigue me :)

If you like that, you'll love "wave pipelining", where the information ripples across a circuit with different sub-cycle phases at different positions in the circuit.

Why isn't more of the control logic inside the sdram chip/package? Even if you want to save pins it seems the interface could be much simpler.

SDRAM is designed to have as much of the complexity located in the controller and as little as possible in the DRAM chip itself.

This makes sense because you'd have a lot of duplicated logic when you gang multiple DRAMs together.

It allows the chip designer to make trade-offs between design complexity and performance. Modern DRAM controllers can be incredibly complex (and large!) when dealing with different kinds of traffic at the same time: prioritizing CPU traffic, which is latency sensitive, over graphics workloads, which is not.

Another, close to the metal, example is the the source-synchronous data strobe signal that travels with the data from the controller to DDR DRAM or the other way around.

Going from the controller to the DRAM, it is 90 degrees out of phase with the data, which allows the DRAM to clock in the data using the rising and falling edge of the DQS signal. It's on the controller to create this 90 degrees phase shift with a DLL or PLL.

But the other way around, from DRAM to the controller, there is a 0 degrees phase shift, once again forcing the controller to create a 90 degrees shifted signal.

This also makes is possible for the DRAM drop DLL and PLL logic in some cases.

The more-complex interface makes it possible to optimize performance with very fine adjustments - for instance, sufficiently-modern DRAM can be precharging one bank while also servicing data requests from an already precharged one. It can also help with specific data-access patterns: for instance, if the FPGA always reads a whole page then a single precharge could serve for many reads.

If you want a giant ring buffer with deterministic low latency, manual refresh control is a godsend.

They make those too. HyperRAM is pretty popular for small FPGA projects: https://www.mouser.com/new/issi/issi-hyperram/ - there are tradeoffs in potential performance/interface/usability/etc but you end up saving a lot of LUT's and troubleshooting time.

Is there free and functional controller for HyperRAM available? In theory this type of memory is nice, but with no free IP block for this memory, it is a show stopper.

Here you go: https://github.com/blackmesalabs/hyperram

The controller is really not very complex, so it shouldn't be a showstopper.

SDRAM is cool but DDR3 is better! With LiteDRAM there is even an open source controller. LiteDRAM also works with SDRAM too.

DDR3 is SDRAM, isn't it?

These days we call it "SDR" ram for single data rate. But when it was current it was just called "SDRAM". So yes technically all are synchronous dynamic RAM. But the colloquial terms are SDRAM (or SDR), DDR, DDR2, DDR3.

But if you want to get super technical later DDR standards aren't really synchronous at all. There's a huge analogue component and the input clock is only a reference to feed on board PLLs and calibrate delay lines. It's simply not possible to do a traditional synchronous design at the frequencies involved.

Yes. SDRAM is just synchronous DRAM and I think the last asynchronous DRAM type in widespread usage was probably EDO DRAM from the early 1990's.

The first synchronous DRAM type was called SDRAM and that was followed by all of the DDR standards which still use a clock and are there synchronous in operation.

SDRAM control is fairly simple to implement almost right from the state diagrams. Squeezing performance out of the chips is a different matter.

Looking at my own controller code from about 15 years ago, you need a 34 state one-hot state machine and the rest comes right out of the diagram and data sheets. Careful placement and layout (I'm talking both about within the FPGA and on the PCB) does the rest. For example, for best performance you want some of the flip-flops located right at the IOB's.

Still, it's cool that something like this is available for those who, for whatever reason, might choose not to undertake writing their own. Nice.

This is outstanding, thanks Josh! I’ve been getting started with FPGAs and a simple dynamic memory interface with comments and discussion is a huge help.

Awesome job. I particularly like the size of the code. When I see that state diagram, or think about what you have to do to control DRAM, or look at other COTS and OpenSource controller cores, I always was super leery of the complexity. This is very tight and clean!

Looks like you used wavedrom for timing diagrams. What did you use to make the state diagrams?

As an aside: it looks like the timing diagrams in this article were created with a tool called WaveDrom. I've used this tool in the past and been impressed with what it's able to do in terms of creating nice timing diagrams for digital design documentation, a critical part of communicating how these designs (and interfaces!) are supposed to work.

This is very well written and the code looks very clean!

It's a bit verbose, but mostly because he makes everything parametrized so you can easily customize it for different targets.

There are only two things I don't like: he is calling some registers latches and he is mixing std_logic_vector and unsigned in the interface.

What compilers are people using for FPGAs? It seems all the compilers are proprietary, and not much fun to use on Linux.

There has been significant progress in reverse engineering bitstream formats of some FPGAs which has allowed the development of open source FPGA workflows. If you want to know more, take a look at:

Icestorm http://www.clifford.at/icestorm/

Yosys http://www.clifford.at/yosys/

NextPNR https://github.com/YosysHQ/nextpnr

SymbiFlow https://symbiflow.github.io/

At work I use Vivado. It's proprietary but I've never had any problems using it on Linux. I believe there are free editions as well. It has the same problems all FPGA tooling has (bloated, slow build times, not user friendly). Maybe some of the open source tooling improves on that, but I've never heard of anyone using it for real projects. Last I checked the open source stuff also only supported Verilog (not sure if it supports SystemVerilog too). Not the end of the world, but a lot of projects use VHDL or are mixed language.

Edit: Mostly people just use whatever software the FPGA vendor provides. So for Xilinx you use Vivado. For Intel/Altera people use Quartus. Some people do development in an IDE like Sigasi (which I've heard is much better than the vendor specific IDE's, but I've never used it), but they still build with the vendor tooling.

> At work I use Vivado

As an enthusiast, that's what I use too.. also on my home Linux system. The tooling is generic enough that you can actually instrument a build system with Makefiles and the Vivado command line programs. If you have the right FPGA board you can also instrument the bitstream upload as well.

I do most of my development like any other programming language and never have to touch the custom GUIs.

The tools aren't much fun on Windows, either.

Reply on news.ycombinator.com