SDRAM and DMA support?

John A. Zoidberg

Hey there,

I hope this question doesn't annoy you guys - I've read through a bit of the development thread, and I noticed that SDRAM is not mentioned a lot here, and also the DMA.

It would be extremely good if I can interface it to an 8 megabyte SDRAM, and then program code and frame buffer all inside. Is it workable?

And the DMA - more advanced microcontrollers use them. It would be helpful to push the pixels faster, isn't it?

Rayman

I think we're leaning toward HyperRam with DDR and 8-bit bus. Saves a lot of pins...

evanh

The Streamers are the DMA engines of the Prop2 - 16 effective channels - one in each Cog. And, yep, Chip intends they be used for SDRAM, amongst many other uses.

Not to mention a Cog itself can be treated as an effective DMA engine when viewed from other Cogs.

evanh

Rayman wrote: »

I think we're leaning toward HyperRam with DDR and 8-bit bus. Saves a lot of pins...

The DDR thing has been a bit of a surprise bonus it seems. Since there is no specialised clock out resources on the Prop2 then the Streamer has to rely on an emulated clock using a counter toggle or something. This resulted in a max output clock speed of 1/2 sys-clock. Which turns out to be perfect for a DDR bus to feed a Streamer at top speed.

I certainly hadn't foreseen that outcome.

evanh

Presumably even DDR SDRAM could be driven in a similar fashion. DDR2 is rated for 1.8 volts so seems compatible. DDR3 at 1.5 volts not so much.

rogloh

Hi John,

I managed to develop an SDRAM interface on the P1V (got it going for both MAX10 and DE-Nano based boards) which seems to work fairly well and is mapped directly into hub memory address space - still need to link in the framebuffer portion, but that is also supported in the design. If/when P2V gets released it may be possible to do something similar with SDRAM and an FPGA. But that might be a while...

One issue with the P2 device and SDRAM is the total pin count. For a 8MB SDRAM you are going to need about 37-38 pins to drive it, that's quite a fair chunk of the 64 pins taken up on P2 when you consider you will also probably want a parallel video interface and boot flash etc. Old P2-hot was better in that respect with more total pins left over after adding an SDRAM interface.

HyperRAM throughput and low pin count looks pretty good for P2, though in my view it's probably the overall write latency performance that will get you if you are using it for streaming video at the same time as wanting to write to it. Some sort of smart PASM arbiter will be required to mediate access between writer(s) and reader(s) so as not to starve out writes until blanking portions etc while at the same time giving sufficient read bandwidth to the video rendering process.

One way around that problem is to have two separate memory banks and just flip between them, so one bank is fully read/writeable, and the other is rendering video to an output device, then you flip pages. P2 has enough pins for two sets of HyperRAMs and even doing that still uses less pins than an SDRAM. But then you have to deal with the fun of managing two frame buffers and try to keep them in sync, it probably creates 2x the number of writes.

Tubular

I think Chip definitely had SDRAM intentions. He spent some time getting P2-Hot talking to SDram.

The P123-A7 had a memory slot and the voltage could be set (1v8, 2v5, 3v3 etc).

The P123-A9 has a memory chip soldered. I don't have the detail with me, but will report back what chip is on there

But HyperRam seems to be the current focus for the rest of us, if not Chip

John A. Zoidberg

Ah, but is there some sort of option for any users to switch the memory modes? HyperRAM is not really sold in a lot of places right now, and SDRAM is the more common thing for everyone there. When would they actually have HyperBuses for the mainstream microcontrollers?

evanh

John,
Is that a question about the Prop2 or other uControllers? Prop2 support, of course, is not hard coded for any of these so can switch external memory type at will even at run-time.

Which also means that support code is required to make any of them work.

John A. Zoidberg

evanh wrote: »

John,
Is that a question about the Prop2 or other uControllers? Prop2 support, of course, is not hard coded for any of these so can switch external memory type at will even at run-time.

Which also means that support code is required to make any of them work.

Ah, it's for the Prop2. Like other microcontrollers, memory interfaces can be switched for users who want a HyperBus, or an SDRAM.

evanh

I assume that was meant say Unlike other microcontrollers. Typically a DRAM controller is not part of a uController. And it isn't here either, just it's easy to have multiple Cogs doing their own thing with the Prop.