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: <a href="http://codehackcreate.com/archives/444" rel="nofollow">http://codehackcreate.com/archives/444</a><p>The notes on getting the clocking right are also very much appreciated; that's always tricky with SDRAM.
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 :)<p>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 :)
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 control is fairly simple to implement almost right from the state diagrams. Squeezing performance out of the chips is a different matter.<p>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.<p>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!<p>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!<p>It's a bit verbose, but mostly because he makes everything parametrized so you can easily customize it for different targets.<p>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.