LPC43xx: EMC (SDRAM), GPDMA

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Apr 17 08:23:35 MST 2014
Hello,

is there any document other than the UM that explains in more detail the operation of the EMC when operating in SDRAM mode?
I'm trying to calculate the bus saturation (internal and from the LPC to the SDRAM) when moving samples from the ADCHS to SDRAM.
For this I would like to understand how the EMC buffers write data and whether it combines write bursts to the same page (row) of the SDRAM.
The UM mentions four buffers, each containing 16 words and that the EMC will do (only!) burst transactions of 4 words. The latter is a bit surprising (does it really write 4 words if I'm going to write a single byte?. Yes, technically feasible, but would involve 3 write transactions with all DQM inactive ..).
However, for my application bursts of 4 are nice enough.
The UM also says a bit about when the EMC will flush a buffer. Yet I miss some information or simply look in the wrong place:

- If a buffer contains more than 4 words at "flush time": Does the EMC produce back-to-back write bursts or does it produce several "self contained" bursts like: activate row -> write burst -> precharge?
- are these 4 buffers statically allocated to the four DYCS regions or can the EMC use all 4 buffers on a single SDRAM (DYCS), if there is only one?
- can I somehow "help" the EMC to produce the most effective sequence of SDRAM transactions by filling the buffers in certain way?

Likewise I would like to understand the speed of the GPDMA, especially arbitration issues, better.
How many cycles does the GPDMA require for arbiration when the AHB is idle (hopefully at most 1)?
I understand that it is not a fly-by DMA from ADCHS to the EMC but uses a read to FIFO, write from FIFO approach (like flow-through), thus requiering 2 cycles per transfer minimum.
Since the FIFO seems to have 4 words: if I program a burst size of 8, will it do 4 source reads to fill the FIFO, followed by 4 destination writes and then repeate that sequence a second time or will it read/write 8 times in succession, as long as source and destination are availabe at request time?

If there are documents explaining these kind of items I'd be happy to read them ...

Regards,

Mike

[lpcware]

Content originally posted in LPCWare by AkshayHV on Thu Jan 15 22:28:18 MST 2015
Hello Mike,

Thanks for your reply, Now we are using the CPLD which is writing ADC values to the SRAM. Since we are using a TFT Display with emwin ported we use SDRAM on our controller board. is it possible to interface SRAM as well as SDRAM to LPC1788.

regards
Akshay H V

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Jan 02 07:12:31 MST 2015
Hello Akshay,

this is just what I mentioned in my reply: You simply run into  the bandwidth limit of the uC.
The loop, which is cancelled by the timer, is just fine, but the assembly of the bytes into words must be be done by HW. The SW method is simply taking too much time, remember, you only have 2 cycles to process a byte and even a jump to the start to the loop will take 2 cycles.
So a loop doing just nothing like

while(1);

consumes ALL the cycles you have to spend!
No nothing in the body of the loop!

The

*char_wr++ = variable;

consumes also 2 cycles (which is pretty good anyway!).

I still think you get either the SGPIO to help you assembling the bytes to words or you must do that externally via latches.
I myself would not even be totally happy with an unrolled version of the loop like

while(1)
{
  *p++=GPIO;
  *p++=GPIO;
  *p++=GPIO;
   ...

}

because I would be aufraid of synchronization issues (ADC->GPIO). Without an EXACTLY matching and phase locked clock I'd be afraid of violating sample/hold times and getting invalid data sampled by the GPIOs.

This is where the SPGIO could really help since as far as I can see you could use it to generate the 100MHz clock for the A/D-interface and all the control signals in sync with it. Tough job, though.

If you are testing a variable for loop abort, it will naturally reside in memory and each test also consumes time. Maybe you can "trick" it into a register for the time the loop runs and modify that register in the timer ISR - not straightforward either.

The more I think about it the more I get the impression you will end up with additional HW between the ADC and the µC.
Something like a small/cheap CPLD to assemble the data.

I really wished I could help you with a stunning solution ... does not look like it will happen.

I don't know what your application is, but well, if it's not for commercial sale, maybe you could try to overclock the 80 MSPS ADC of the LPC4370, it's not that far away ...
Remember, I'n not affiliated with NXP :)

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by AkshayHV on Fri Jan 02 05:50:49 MST 2015
Hello mike,

thanks for the reply again.I will explain how I just tried now, I started a timer with mat interrupt of 1Second. after starting the timer i wrote a while(1) there I started to put dummy data into a 32 bit variable and started to store that in to the RAM  as shown below.

while(status)
{
variable = (0xf1 << 24);
variable |= (0xf2 << 16);
variable |= (0xf3 << 8);
variable |= 0xf4;
*char_wr++ = variable;
}
here the status will be 1 in the start of the program, once the timer is elapsed i will make that status as 0 inside timer handler.

as far as the ADC is 100Mhz we must get 100M samples per second.
But after the exit of this loop i accessed the address of that char_wr pointer which is pointing to the SDRAM address.I got to know that from the start address I had initialized for that pointer it was incremented for only to store 14700000 samples only.

So is there any other way to overcome this speed issue.

regards
Akshay H V

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Jan 02 03:21:33 MST 2015
Hi Akshay,

in this case I think you will hit the bandwith limit already on the "input side". You can run the Cores/AHB at 200MHz.
At 100MSPS in a byte wide fashion you will have exactly 2 cycles for each byte to be read and stored.
I cannot think of a SW loop that does this.
The best I can think of is an unrolled version of a loop that can actually sustain the 2 clock read/write, but at some time you must branch back and then one sample will be lost.
This is consistent with your 40ms result.

Of course, start/stop of the loop must then be controlled by other means, e.g. a timer.

You won't win anything by simply bypassing the uC (direct connection of the ADC to the SDRAM) since the SDRAM also has limited burst length, same problem here (you only have once cycle "free" at 125MHz and that won't do it.

In my opinion you must find either a way to assemble the bytes into 32bit words and then write these words to the SDRAM.
If done externally this requires at least 3 8bit latches to buffer 3 samples of the ADC, while the fourth could be read in along with output of the latches.

One module that could be very useful here is the SGPIO module. I have littled personal experience with the module, I use it "the other way round", i.e. to produce patterns.

Maybe it can even be used to to the assembly, it seems to have an "8bit parallel I/O" mode. I doubt it right now, but there are appnotes for the SGPIO which might help. I remember one with an 8 bit camera interface.

If there is no feasible solution with the SGPIO alone then I'd go for the 3 latches and use some SPGIO lines to procude the required control signals for the latches.
At this point that's the best I can imagine.

Good luck,

Mike

[lpcware]

Content originally posted in LPCWare by AkshayHV on Thu Jan 01 21:45:31 MST 2015
Hello Mike,

Thanks for the reply.Yes the ADC which we are using is a 100 MSPS 8 bit ADC.

regards
Akshay H V

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Jan 01 05:41:40 MST 2015
Hello Akshay,

before I comment further, please confirm that you are talking about a 100MSPS 8bit ADC.

Regards,

Mike

[lpcware]

Content originally posted in LPCWare by AkshayHV on Thu Jan 01 04:20:35 MST 2015
Hello Mike,

we also have a same requirement as you . we want to write 2000000 bytes within a time of 20ms which is read by GPIO ports ,since we are using a external 8 bit parallel ADC and the external ram we are using is a MT48LC4M32B2 which can operate at a speed up to 125 MHz.

I tried to write dummy 1 byte data into the SDRAM using a for loop which will loop for 2000000 times by taking the address of SDRAM and assigning it to a char* and was putting the data into that pointer and was incrementing that pointer every time.But the time taken for the completion of my loop  was 140 ms.

Then I tested the speed of my controller by removing the writing to the SDRAM to only test the execution time of my for loop it is taking 40ms.
so i was thinking to connect the data lines of SDRAM directly to the ADC output and then control the SDRAM memory allocation form controller
is it possible to do that.

regards
AKSHAY H V

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Apr 18 09:56:12 MST 2014
Hi mc,

thanks, I did indeed read this appnote already. It provides valuable information about the hardware side of the EMC.
It was quite useful for understanding the use of the clock signals + internal feedbacks to the SDRAM and I made provisions on the board according to the appnote. Quite helpful!

Unfortunately it tells nothing about the use of the buffers within the EMC and how the EMC decides when it will activate or close (precharge) rows.
This latter information would be very useful on the software side, especially when one is scratching (probably) at the bandwidth limit.

When I stream the full 80 MSamples of the fast ADC to SDRAM, I'll have to transfer 160 MBytes/s to the SDRAM.
Of course I'll try to get away with cheap SDRAM, that is I would use 100 MHz clock and a CAS latency of 3 cycles (if neccessary, I'll go for 2 cycles).

The LPC4370 has enough buffers to cope with the interspersed refresh cycles or row crossings, if only the EMC can write bursts at an avarage of 9 cycles within a row.
But in order to check for this I'd need the information mentioned above.


Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by mc on Fri Apr 18 07:33:52 MST 2014
Hi mch0,
Please see application note for LPC18xx/LPC43xx at
http://www.nxp.com/documents/application_note/AN11508.pdf