• AVR Freaks

32 mb SDRAM via EBI -- WORKS!

Author
tj256
Senior Member
  • Total Posts : 103
  • Reward points : 0
  • Joined: 2014/10/12 21:06:01
  • Location: 0
  • Status: offline
2015/09/08 07:11:59 (permalink)
5 (1)

32 mb SDRAM via EBI -- WORKS!

The title might be misleading because there's alot of work involved, but I wanted  others to know that it is indeed possible to get 20ns performance for linear access from a $3 external memory chip.
 
When weighing my memory options recently I was reminded how expensive SRAM is. Nearly $20 for a fast SRAM nearly doubles my silicon cost. Unfortunatly I need write speed of 20ns so I had no choice. 
 
After thinking about it, I decided to drop a $5 FPGA on my board and a $3 SDRAM memory chip and learn verilog in the process. After all, I'd get an FPGA for free (to fix all the other issues I'm having with this blasted chip) and $8 for the memory. Seemed like a good deal.
 
While I can't release my design, I think what's more useful to you out there is knowing that it's not hard to do this and that the EBI works "good enough" to do this.
 
To get it to work properly, there are a few "features" I took advantage of in EBI that weren't really there for general purpose but their inclusion was key in allowing this to happen. 
 
First thing to know is that SDRAM takes time to go fetch a burst of 8 words. But that time is averaged over the 8 words so it winds up giving 20 ns performance per BYTE on a 50 mhz bus. That's 50 MB/sec. The unfortuante thing is that EBI has tonnnes of bugs that slow it down to this level. It is very possible to have 200 MB/sec with this bus design (EBI) but these bugs kill performance.
 
 
Anyway, EBI is configured :
 
1) 50 mhz -- for SRAM (This makes me cringe that they did this. 1 for SRAM, 2 for NOR-- this is supposed to be general purpose!)
 
2)  Page read - This is KEY-- because it lets you use the tRC delay to hide the memory read. The address is presented on the bus .. tRC occurs... then you hand out the result.
 
3) CACHE configured in the tlb. You have to map the address space of the EBI window using TLB. Turning on cache makes the transactions appear (always) as bursts of one cache line in size.  This is key because if it were doing 1 byte/word at a time the performance would be terrible. You'd have to pay tRC (6 or so clock) read latency per word instead of for a set of 8!
 
4) EBI clock generated inside the FPGA. This is a project in itself since you can't output PBCLK8 (the EBI clock). You have to clock in EBI data on the rising edge of this clock and there's no way to get it out of the chip! And if you output another clock it will have a random phase shift! The trick is to run a clock at 200 mhz sourced from a reference clock output from the pick (use your fpga's PLL to do this). Then divide it down to get the 50 mhz EBI clock. To get it at the same phase, reset the divider when the EBI's chip select falls. This should line up all transitions from the PIC on the falling clock edge. You read on the rising edge.
 
The last thing is that for both reads and write EBI transactions is that I keep a "window" of time free ahead of the corresponding SDRAM transaction. This slot is used to do refresh when needed, and could also be used as a 2nd port. The sad thing is that running without the /READY line on EBI makes you have to "fix" the timing so it doesn't change. SO no matter what this slot has to be there. This slows things down a bit.
 
Using /READY is a non-starter unfortunately. This requires about 3 clocks per word which is terrible performance. But with the 8 word burst for read/write I am getting about 40 mb/sec for both reads and writes UNLESS I hit the tRC bug below. When that happens I drop to about 15 mb/sec for reads. I am trying to see if microchip will fix this but if the past is a reference probably not. BUT if your application (like mine) keeps the fast reads/writes linear then you don't hit this and keep the 40-50 mb/sec rate.
 
This is pretty much all you need to know. Armed with this and the timing diagrams of SDRAM and some good FPGA tools you can do it too. 
 
Now for the EBI bugs-- just about everything on this chip is a bit brain damanged and EBI is no exception:
 
1) If a read is performed on a cache line that isn't loaded and it is a read of an address that isn't on a 16 byte boundry you pay for tRC twice. The read will actually start at the requested address (not rounded down!) and wrap around at the high end of the 16 byte boundry back down to the low end of the boundry When it does this you pay for tRC again! This is super annoying and reduces read performance.
 
2) There are spurious read transactions in a cache write. To filter these, just assume that when a write comes in that you will get 8 words and ignore any reads. 
 
3) The EBI claims that you can clock it at 100 mhz so long as you observe the min timing in the family datasheets. I've found that running at 100mhz gives you flaky performance. The address lines for example glitch. I haven't determined for sure that it isn't an SI issue on my board but I don't think it is.
 
4) There are strange delays in between every 2 words written. This may be a bandwidth limitation inside the PIC32 but it isn't documented.
 
Anyway... it IS possible.. but Microchip threw some challenges in there for ya :) 
 

post edited by tj256 - 2015/09/08 07:26:23

Attached Image(s)

#1

9 Replies Related Threads

    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11220
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/08 12:09:38 (permalink)
    3 (1)
    When I first looked at the MZ data sheet, I was surprised to see it didn't have a controller for cost-effective external RAM, when there are competing products at the same price that do. 
    #2
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/08 16:03:25 (permalink)
    0
    I agree-- I picked the PIC32 simply because it is much easier to get up and running than something like a regular Soc (IMX from freescale for example). But now I realize that this isn't the case-- so much stuff is broken and/or missing that it's actually more work. 
     
    For me, I thought my memory requirements would be 2MB but as usual features are added and 32 mb meant I had to figure out how to get SDRAM working. LOTS of work for sure. It's been a wild ride for me over the past year and a half...
     
    1) Suffered with a slow, crashing, unreliable NetBeans based GUI that would randomly hang, freeze, and otherwise bring a 8gb i7 to it's knees. I eventually gave up on this and moved to J-Link/eclipse
     
    2) Eventually threw in the towel on Harmony due to bugs and bloat.
     
    3) Hit bugs in the ADC, SQI, SPI, XTAL... just about everything I try to use is broke in some way
     
    4) Ran out of memory ... now this adventure :)
     
    After having used Microchip for just shy of 20 years (wow... that's crazy!)  I have to say that this is my last project with Microchip.  I'm not sure what's happened over there, but given that they've licensed the MIPS core all they have to do is peripherals. So why are they poorly designed and generally broke? Just strange. Also, The old MPLAB was better than what they have. Harmony? That shows me that they don't understand their customer and how to design lightweight frameworks (or really code at all to be honest-- these are bloatware coders that you'd find under windows writing this stuff not embedded software programmers. Fat machines hide the slop but not in this market.). 
     
    I agree-- competitors seem to be getting it right. I am really not sure why I didn't look harder before I started so I have to deal. But not next time.
     
    #3
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11220
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/08 16:58:23 (permalink)
    3 (1)
    I agree-- competitors seem to be getting it right.

     
    Well, the part I'm using because it had an SDRAM controller and 2 Msps ADC, turned out to have a 1.7 Msps ADC, and I was the first person to discover that.  The response from the factory was not "we'll fix that in the next silicon spin", it was, "we'll correct the data sheet."  So the design ended up with an expensive external ADC, though it was still cheaper than SRAM.
     
    So the competitors might seem to be getting it right...
    #4
    andersm
    Super Member
    • Total Posts : 2605
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/08 20:02:47 (permalink)
    0
    Some old Microchip roadmaps show a part with DRAM support scheduled for release in 2014, but the same document shows an EC that's slightly different from the released one. You could try all possible settings for the MEMTYPE bits and see if the bus starts outputting a refresh signal...
     
    The PIC32MZEC/EF datasheets claim a 50MHz EBI under features, where did the 100MHz figure come from?
    #5
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/08 20:47:36 (permalink)
    0
    That's interesting about the SDRAM in the road map. Makes sense that they'd put it in the list of 1) SRAM, 2) nor, 3) SDRAM? how about 4) DDR3. Lol.
     
    andersm
    The PIC32MZEC/EF datasheets claim a 50MHz EBI under features, where did the 100MHz figure come from?



    This is one of my annoyances with Microchip. They are inconsistent in their own docs. If you look at the latest datasheets you'll see the 10ns clock rate in "TABLE 37-46:EBI TIMING REQUIREMENTS", yet elsewhere they say 50 mhz.
     
    Now that I've done the work, I don't want to give control of my ram back to microchip ;)
     
    The bonus I didn't mention is that I've implemented my own DMA on the 2nd port in the FPGA so I can do things like have a frame buffer at no cost. I think at this stage I will continue to "take things away" since the less you depend on functionality in this chip the better I've found. Offload to an FPGA seems to be the way to go. At least for me.
     
    Maybe SDRAM was a stretch goal that fell off the map due to the many fires that broke out.
    post edited by tj256 - 2015/09/08 20:54:47
    #6
    jdeguire
    Super Member
    • Total Posts : 463
    • Reward points : 0
    • Joined: 2012/01/13 07:48:44
    • Location: United States
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/09 05:51:49 (permalink)
    3 (1)
    In Harmony v1.05, I think, there is a "ddr" peripheral library which references a PIC32MZ2064DAB288 part that of course does not yet exist.  Harmony v1.06 removed that peripheral, but makes more references to PIC32MZ DA series parts, which seem to also have a built-in display controller.  Microchip is probably working on a part with an SDRAM controller, but who knows when it'll actually be announced.
    #7
    aschen0866
    Super Member
    • Total Posts : 4469
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/09 07:48:12 (permalink)
    3 (1)
    The DA will have DDR2 SDRAM support, internal 32MB or external up to 128MB. It is scheduled to release sometime next year. However, it won't be a drop-in replacement for any existing EC or EF parts. Your FAE should be able to get you the preliminary datasheet.
    #8
    andersm
    Super Member
    • Total Posts : 2605
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/09 08:33:23 (permalink)
    0
    This was the roadmap in early 2013. The PIC32MZ EC fiasco obviously caused a lot of changes, and in the meanwhile imgTec also got their first microAptiv core with an FPU finished, which became the MZ EF.

    Attached Image(s)

    #9
    tj256
    Senior Member
    • Total Posts : 103
    • Reward points : 0
    • Joined: 2014/10/12 21:06:01
    • Location: 0
    • Status: offline
    Re: 32 mb SDRAM via EBI -- WORKS! 2015/09/09 11:21:47 (permalink)
    4.67 (3)
    jdeguire
     Microchip is probably working on a part with an SDRAM controller, but who knows when it'll actually be announced.



    They're talking about external graphics , FPU's, and DDR controllers. We have plugins and harmony configuratiors and graphical ways to set registers and all kinds of fancy stuff being done at MC-- but things like the CPU clock don't work after 5 revisions.
     
    I'd like to see them stop trying to chase these things and just get one chip with the basics working. I STILL can't view EBI memory in the debugger, yet the (broken) bells and whistles keep coming.
     
    They seem to be forgetting-- this is a MICROCONTROLLER. I think it's great they are giving us serious performance at 200 mhz and a MIPS core. But with all the brokenness it fails to deliver. Then they think it's a mobile cell phone processor. That's not the main market as far as I know. I don't care for touch screens and all that. Give me I/O so I can add it if I want. But the basics aren't being delivered-- namely an embedded processor with I/O that works. (working tools would be nice too.)
     
    The buzz is too thick to deal with these days. A working product has fallen by the wayside.
    post edited by tj256 - 2015/09/09 11:27:31
    #10
    Jump to:
    © 2019 APG vNext Commercial Version 4.5