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?
Using SDRAM in FPGA Designs
11–20 of 26 posts
Re: Using SDRAM in FPGA Designs
#12Why 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.
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.
Re: Using SDRAM in FPGA Designs
#13SDRAM 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?
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.
Re: Using SDRAM in FPGA Designs
#14What compilers are people using for FPGAs? It seems all the compilers are proprietary, and not much fun to use on Linux.
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…
> 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.
Re: Using SDRAM in FPGA Designs
#15Why 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.
Re: Using SDRAM in FPGA Designs
#16SDRAM 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.
Re: Using SDRAM in FPGA Designs
#17As 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.
Re: Using SDRAM in FPGA Designs
#18What compilers are people using for FPGAs? It seems all the compilers are proprietary, and not much fun to use on Linux.
The tools aren't much fun on Windows, either.
Re: Using SDRAM in FPGA Designs
#19Thank 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.
Re: Using SDRAM in FPGA Designs
#20Why 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.
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.