Hi, On Monday 19 October 2009 11:31:59 Zeus Gómez Marmolejo wrote: > I was planning to use the HPDMC instead of the YADMC in > my project, but I have some questions. > > First of all, I would like to use the SDRAM as storage for the VGA > framebuffer... And I see that you are using it in that way, which is very > surprising to me... I thought that accesses to the SDRAM could take a lot > of cycles: first to prepare the address and wait for acknowledge from the > SDRAM chip... Also if a memory refresh is taking place, this may affect > the response time of the memory. How you can handle that with the > framebuffer? If data is not ready, it can't be drawn correctly, isn´t it?
Why is it so surprising? The video chip connected to the monitor you are looking at right now does that. As a general rule, memory latency is only a serious problem when you have a dependency between the address of the next access and the data that your are reading. If there is no such dependency, you always have the option of requesting the data from the memory controller sufficiently in advance so that the data has arrived when it is required. In the VGA framebuffer case, the addresses and the data are completely independent (you are always scanning the same buffer over and over again regardless of the image content). The problem is solved in Milkymist (and in many other designs) by using a FIFO buffer that refills itself from memory as soon as is has enough space to store a SDRAM burst, and which keeps a sufficient filling margin to ensure an uninterrupted feed of pixels to the video DAC, even in the worst case with a maximum (bounded) memory access time (which includes not only DRAM refresh issues and CAS latency but also page miss penalties and FML bus arbitration). In other words, if the FIFO is deep enough, it will not get empty (and interrupt the stream of pixels) before your memory request completes. The only real issue becomes the average bandwidth that the memory subsystem can sustain. At 100MHz, the SDRAM control algorithm in HPDMC squeezes more than enough bandwidth from the memory chips to support 640x...@60hz (and probably higher resolutions) while at the same time leaving some bandwidth available for the CPU and other bus masters such as the texture mapping unit. Laptop chipsets that support "shared video memory" such as the Intel i810 face a similar constraint (and that's why increasing the video resolution or refresh rate on such machines slightly slows down the CPU). > Apart from that, I see that HPDMC is only compatible with Xilinx FPGAs due > to its primitives. The only primitives are the double-data-rate I/O buffers (timing constraints are too tight for them to be inferred) and IDELAYs. Neither should be needed for SDR. > I was trying to think how this can be ported... For > example the Altera DE1 has a SDRAM but is not DDR, and the Altera DE0 (a > new, very cheap board) has a DDR. Do you think the controller can be used > for both of them, without major changes? For SDR, yes, just get rid of the IDELAYs (you most probably have sufficient timing margins to get away without them) and replace the DDR buffers with normal registers (D flip-flops) that you can infer. Enable IOB register packing if possible (or the Altera equivalent). You will also need to adapt the SDRAM initialization sequence in the BIOS (see function ddrinit in main.c). For your information, HPDMC with these modifications has been shown to work on SDR SDRAM by a NASA laboratory. For DDR, you need at least to find suitable double-data-rate buffers in Altera primitives, and I am too unfamiliar with the architecture of Altera devices to tell you which ones you should use. > I was thinking also to avoid using the IDELAY primitive, and use a fixed > delay parameter for the PLL, do you think this is possible? Yes, it is. Depending on your clock skew you might even not need a PLL at all. Best regards, Sébastien _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkym...@freenode Webchat: www.milkymist.org/irc.html Wiki: www.milkymist.org/wiki
