Hacker News Reader

Comment by LeonM | Hacker News Reader

> Alas, I am told by my friends that DDR controllers are no joke; they are not the playground of bored SW engineers.

No, they definitely aren't funny. I've worked with FPGAs and DDR controllers at college and their can be a big PITA. Even with DDR controller libraries you can still run into all sorts of timing issues.

View on HN

When a SWE really starts to understand how complex a modern DDR controller is at the silicon level, two things happen:

1. You start to wonder how very, very far your code runs from the theoretical capabilities of the hardware and you start experiencing existential doubts.

2. You are overcome by a deep and immense feeling of gratitude towards whomever managed to force all that complexity to remain hidden underneath the simple memory abstraction your rely on to write day to day code.

Any links to reading materials for learning about that?

Found this PDF from Samsung regarding the DDR4 interface itself:

https://www.samsung.com/semiconductor/global.semi/file/resou...

(The JEDEC DDR4 spec is $284 to download...)

Start reading data sheets of memory chips. They have state diagrams. DDR2 is great technology to start with. Some random memory chip: https://www.micron.com/-/media/client/global/documents/produ... on page 9 you have state diagram. There is simulation model available.

Where is this simulation model, and (here's hoping) is it cross-platform?

Also, is it anything like http://www.visual6502.org/JSSim/?

On Micron’s website for most of their parts. Worked very well with Alteras’s memory controller some time ago. I needed to evaluate read write throughput for specific read/write patterns before designing printed circuit boards. I don’t unterstand what you mean with cross-platform.

I try really hard to not go down that particular rabbit hole as it will always end up being 100% sure that software can't possibly work reliably or even at all. The degree to which we assume that our hardware is able to move stuff from point 'a' to point 'b' at a couple of billion times per second is scary.

Although I don't know hardware, I read lots of stuff about developing it to get a better idea. Among the more interesting reads were slides about each process shrink along with challenges they brought. Especially from beginning of Deep Sub-Micron toward 28nm.

The impression I got, esp by 28nm, is the hardware is inherently broken in quite a few ways. They have to correct the masks with algorithms, they do image recognition on circuits to spot patterns that act up, extra latches, variance across the chip/wafer, aging effects... list goes on. Miracle they even work at all.

These things are also why I only trust old nodes for security. Sort of.

There's actually an open source DDR4 controller[1]. To my untrained eyes it looks quite complex. It's written in Python using Migen[2] to generate the HDL.

[1] https://github.com/enjoy-digital/litedram

[2] https://github.com/m-labs/migen

It's very easy to make a DDR interface in an FPGA, it's difficult to make it run at the mark speed...

(but this observation is generic for all FPGA-stuff really, it seems easy first, it's just another language etc.. but you need to learn timing analysis and constraints and optimization to use it for real)

The Spartan-6 has a DDR memory controller built in.

Edit: I was wrong and confused the Spartan 6 of the Pano G2 with the Spartan 3 of the G1.

Spartan-6 does not.

But Xilinx has a MIG (memory interface generator) that automatically creates the RTL for a memory controller that synthesizes to regular core logic.

In addition, it also has IO cells with posedge and negedge FFs and calibrated delay lines.

Getting the DDR DRAM to work on the Pano G2 shouldn’t be too hard. (Less hard than the G1, which has DRAM that isn’t supported by the MIG.)

Well UG388 claims that it does have a hard memory controller block.

I stand corrected!

I really should get the DRAM working on the G2. How hard could it be?

Famous last words. But I do hope you manage to get access to that sweet memory, it would make software life so much easier.

A couple of weeks of very hard work at a minimum :) Maybe a year or so on the outside. But please do!

How about 9 hours? :-)

Just got it up and running with a 125MHz clock and the Xilinx MIG (memory interface generator.)

Did you connect the the memory controller Xilinx MIG to the AHB interconnect of Leon?

I used a similar DDR2 memory (MT47H64M16 I think) on a Cyclone III a few year ago. Using the ALTMEMPHY from Altera it was not to difficult to make it work. Then later we got a new batch of cards witch would randomly fail. The problem was that DDR had been switched from Micron to an equivalent from Samsung. But the timing must have been just different enough to cause random fails. So yes DDR2 memories can be tricky.

Many years ago at University I used Leon and grlib for a project. It was a nice processor and IP library. I would like to use it again.

Hah! Awesome.

You're right they do, just not on the lowest speed grade devices [1]

[1] https://www.xilinx.com/support/documentation/data_sheets/ds1...

Reply on news.ycombinator.com