26 Jan
2011
26 Jan
'11
10:19 a.m.
I was hoping to share my pain with others as a coping mechanism. :)
Has anyone else worked with DRAM memory controller implementations
within FPGAs?
I have been struggling for a couple years to find a workable solution in
a hobby environment, first on Xilinx and then on Altera.
Both companies seem to push the embedded microprocessor solution,
MicroBlaze and Nios II, respectively, as an answer. They both offer a
built-in memory controller which makes access to the DRAM much much
easier, as it's memory mapped to an address region. But the problem is
that there is a certain amount of overhead associated with using the
processor both in terms of speed and logic utilization. The processors
have a maximum speed and making a "gateway" out of the processor doesn't
work for any real application.
Many people push "opencores" and say there are 30 or 40 open source
memory controllers without realizing that all of the limitations
eliminate 99% of what's out there, including:
Controllers designed for a particular memory architecture/chip type/ bus
width
Custom busses that aren't documented
Some just don't work
Require a specific vendor + FGPA because they use proprietary built-in
hardware
and so on.
There are commercial solutions which cost way too much $$$ and often
have advanced features which complicate use for the average hobbyist.
I need something that has a FIFO-like(or maybe sram-like) interface on
it, and that supports single data rate SDRAM. Something simple.
Anyone else run into problems with getting a working memory controller
for your projects?
Thanks
Keith
26 Jan
26 Jan
10:48 a.m.
On 26/01/11 18:19, Keith M wrote:
Has anyone else worked with DRAM memory controller
implementations
within FPGAs?
If you mean single-data-rate PC100 SDRAM, then yes. I used to use an
OSS/FS IP core until I found out it wouldn't work on the Xilinx
platform. It synthesized, but the resulting microcode wouldn't actually
work...
Ended up rewriting the stupid thing... I started from the ground up,
eliminated the concept of caching reads/writes (I wanted this for a CPU
core which already had an Icache and Dcache built in), and went for the
"simplest option". Took me about three days to get it working and
properly parameterise the Verilog code.
You can change (at build time):
Data bus width (link to CPU)
Number of SDRAM column address bits
Number of SDRAM row address bits
Number of SDRAM bank address bits
CAS latency
T_rp, T_rcd, T_rfc, refresh rate, initialisation delay and time
before enabling CKE
None of these are adjustable at runtime; that's been on my TODO list for
about six months. Ideally I want to add a control bus to it, which will
allow the host to change the SDRAM timings as required. I'll probably
need this if I ever want to tie it to a PC SDRAM DIMM.
The hardest part is getting the timing right. Screw up the refresh
timing and your data will mysteriously corrupt itself over time. Screw
up T_rp, T_rcd or T_rfc and you'll have issues with missed reads and
writes. Screw up the initialisation and the chip just plain won't work
right.
And yes, my version works on both the Xilinx and Altera platforms :)
Controllers designed for a particular memory
architecture/chip type/ bus
width
The solution for that is parameterisation.
Custom busses that aren't documented
That's always fun. If it isn't WISHBONE or something similar, then I
won't touch it with a barge pole. Building a WISHBONE-to-AVALON bus
bridge is a pain, too -- I never managed to get mine to work.
Some just don't work
No comment. The 16550 UART and WISHBONE CONMAX cores are pretty nice
once you figure out the interface. The bit-width adapters are buggy (as
in, "don't work at all") and I ended up rewriting them for my use.
Require a specific vendor + FGPA because they use
proprietary built-in
hardware
The LatticeMico32 core falls into this category, but I've forked it and
started maintaining a "vendor independent" patch set. Still haven't got
JTAG Debugging working, but that's probably more a case of "throw some
time at it" than anything else.
I need something that has a FIFO-like(or maybe
sram-like) interface on
it, and that supports single data rate SDRAM. Something simple.
You can't really adapt SDRAM to an SRAM type interface because of the
way SDRAM is addressed. If you're already in the right bank and row,
then you're more or less fine. If not, then you have to do a bank select
and row precharge. That takes a couple of clock cycles to kick in, so
you need to tell the host to wait a little while before reading the data
bus.
With CPUs like the Motorola 68000 series, you just hold nDTACK high for
a little while. With the 6502 you have to stop the clock... though why
would you attach an 8MB or so SDRAM chip to a 6502, anyway?
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
12:29 p.m.
On 1/26/2011 1:48 PM, Philip Pemberton wrote:
On 26/01/11 18:19, Keith M wrote:
I guess that's what I mean. :)
My chip is actually a
A3V64S40ETP is organized as 4-bank x 1,048,576-word x 16-bit Synchronous
DRAM with LVTTL interface.
http://www.zentel.com.tw/download/A3V64S40ETP_v1.1_Zentel.zip
(sorry for zipped pdf)
which seems to have similar specs to a more common
http://www.issi.com/pdf/42S16400.pdf
Has anyone else worked with DRAM memory
controller implementations
within FPGAs?
If you mean single-data-rate PC100 SDRAM, then yes. Ended up rewriting the stupid thing... I started from
the ground up,
eliminated the concept of caching reads/writes (I wanted this for a CPU
core which already had an Icache and Dcache built in), and went for the
"simplest option". Took me about three days to get it working and
properly parameterise the Verilog code.
You can change (at build time):
Data bus width (link to CPU)
Number of SDRAM column address bits
Number of SDRAM row address bits
Number of SDRAM bank address bits
CAS latency
T_rp, T_rcd, T_rfc, refresh rate, initialisation delay and time before
enabling CKE
Jeez. That's pretty good if you can write a dram controller from the
ground up in three days. It took me longer just to get Xilinx's MIG
controller to synthesize.
None of these are adjustable at runtime; that's
been on my TODO list for
about six months. Ideally I want to add a control bus to it, which will
allow the host to change the SDRAM timings as required. I'll probably
need this if I ever want to tie it to a PC SDRAM DIMM.
This "high performance dram memory controller" (hpdmc) has been modified
to work with my memory.
https://github.com/marmolejo/zet/tree/master/cores/hpdmc_sdr16/rtl
It has a control bus and a data bus based on FML("wishbone w/o the
corner cases"?)
http://www.milkymist.org/socdoc/hpdmc.pdf
You can't really adapt SDRAM to an SRAM type
interface because of the
way SDRAM is addressed. If you're already in the right bank and row,
then you're more or less fine. If not, then you have to do a bank select
and row precharge. That takes a couple of clock cycles to kick in, so
you need to tell the host to wait a little while before reading the data
bus.
Maybe not adapt per se, or directly convert, but certainly you could
have an easier to use interface.
Like maybe front-end a small FIFO to the memory controller. Keep
checking the FIFO depth, and read when necessary. There's no
requirement for instant data from the controller.
I guess I should have said "present an easier to use interface" instead
of an "sram-like interface."
Thanks
Keith
3:27 p.m.
On 26/01/11 20:29, Keith M wrote:
My chip is actually a
A3V64S40ETP is organized as 4-bank x 1,048,576-word x 16-bit Synchronous
DRAM with LVTTL interface.
http://www.zentel.com.tw/download/A3V64S40ETP_v1.1_Zentel.zip
(sorry for zipped pdf)
You're using an Altera/Terasic DE1 (Cyclone II Starter Kit) developer
board, aren't you?
Jeez. That's pretty good if you can write a dram
controller from the
ground up in three days. It took me longer just to get Xilinx's MIG
controller to synthesize.
Sometimes it's less effort to write code from scratch than to try and
make someone else's code work...
This "high performance dram memory
controller" (hpdmc) has been modified
to work with my memory.
https://github.com/marmolejo/zet/tree/master/cores/hpdmc_sdr16/rtl
Oh, the Milkymist SDRAM controller core... That should work quite
nicely. Sebastien Bordeauducq is a frickin' good HDL coder...
I didn't use it because I wanted something with a WISHBONE interface,
and there was a (remote) possibility that my project (at the time) might
end up as a commercial product. Hence, introducing GPL code into the HDL
would be a Really Bad Idea.
Maybe not adapt per se, or directly convert, but
certainly you could
have an easier to use interface.
You could have an SRAM-like interface, you'd just need to have a BUSY or
DTACK output to go with it. Is that close enough?
Either way, you're not getting rid of the BUSY output...
Like maybe front-end a small FIFO to the memory
controller. Keep
checking the FIFO depth, and read when necessary. There's no requirement
for instant data from the controller.
Almost all SDRAM chips can handle page reads. Basically, you pick a row,
then read a full page of data out (usually 8 words or so). You could
buffer that in a dual-port RAM. It'll speed up sequential memory access,
at the cost of slowing down random access.
It also falls into the categories "a bit of a pig to implement" and
"can't quite get my head around the logic", which is why it's still on
my to-do list!
Also, I haven't needed it -- the LM32 DCACHE and ICACHE work well enough
for my requirements.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4:38 p.m.
On 1/26/2011 6:27 PM, Philip Pemberton wrote:
On 26/01/11 20:29, Keith M wrote:
Close! A DE0. It has a much more capable, but smaller Cyclone III. (15k
vs 18k LEs on DE1) I like the m9k's in Cyclone III instead of m4k's.
My chip is actually a
A3V64S40ETP is organized as 4-bank x 1,048,576-word x 16-bit Synchronous
DRAM with LVTTL interface.
http://www.zentel.com.tw/download/A3V64S40ETP_v1.1_Zentel.zip
(sorry for zipped pdf)
You're using an Altera/Terasic DE1 (Cyclone II Starter Kit) developer
board, aren't you? Sometimes it's less effort to write code from
scratch than to try and
make someone else's code work...
Sure. I like doing this when I've got a chance of actually succeeding. :)
If I had unlimited free time then it would be on my list.
Wasn't there something about time and skill being interchangeable? If
you lack in one, the other makes up for it. Or something like that?
Oh, the Milkymist SDRAM controller core... That should
work quite
nicely. Sebastien Bordeauducq is a frickin' good HDL coder...
I've been picking his brain recently. Although he's a super-coder, and
I'm still, well, closer to the beginning than the end. :) So he has a
tendency to underestimate the time/skills/knowledge necessary to do
something. I've been chatting with him this week.
You could have an SRAM-like interface, you'd just
need to have a BUSY or
DTACK output to go with it. Is that close enough?
Either way, you're not getting rid of the BUSY output...
Yup. That's basically what I imagined. Once the data is "ready",
something is asserted or cleared, and then you read the data.
Definitely what I had in mind.
Thanks
Keith
5:35 p.m.
On 27/01/11 00:38, Keith M wrote:
Nice. You should be able to get a full LatticeMico32 core in there
without any trouble. Bolt on CONMAX, a 16550 and a Verilog ROM and you
can have your own SoC processor :)
That's basically what WISHBONE is --
- DQ is the data bus
- A is the address bus
- CYC and STB start the transfer. CYC is the bus clock, STB is the
bus enable (strobe).
- R/W tells you whether it's a read (slave -> master) or write
(master -> slave) transaction
- ERR tells the master there was a bus error (generally speaking this
would be generated by a memory mapper or MMU)
- ACK tells the master that the transaction completed successfully
Fairly simple. The timing diagrams in the WISHBONE spec make it very
easy to understand.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
You're
using an Altera/Terasic DE1 (Cyclone II Starter Kit) developer
board, aren't you?
Close! A DE0. It has a much more capable, but smaller Cyclone III. (15k
vs 18k LEs on DE1) I like the m9k's in Cyclone III instead of m4k's. Sure. I like doing this when I've got a chance of
actually succeeding. :)
Oh aye, there's no fun in a project if it's likely to fail.
If I had unlimited free time then it would be on my
list.
I've yet to find anyone with a decent stock of Round Tuits. Apparently
the Law of Equal Exchange dictates that you can't actually *make* a new
Round Tuit unless you already *have* a Round Tuit...
Did I just reference Fullmetal Alchemist on classiccmp?
Wasn't there something about time and skill being
interchangeable? If
you lack in one, the other makes up for it. Or something like that?
I suspect there are limits to that :)
You could have
an SRAM-like interface, you'd just need to have a BUSY or
DTACK output to go with it. Is that close enough?
Either way, you're not getting rid of the BUSY output...
Yup. That's basically what I imagined. Once the data is "ready",
something is asserted or cleared, and then you read the data.
Definitely what I had in mind.
5077
days inactive
5078
days old
5 comments
2 participants
participants (2)
-
classiccmp＠philpem.me.uk -
keithvz＠verizon.net