IMXRT1060 and SRAM in synchro mode

[g_volokh]

Hi All.

I am working with iMXRT1060 and want to use SRAM in synchronous mode via SEMC.

Can anybody give me an example or link how to work with SRAM in synchro mode?

Thanks in advance.

Regards,

George.

[i_osipov]

Thank your very match, Melissa.

I use SEMC/SRAM in sync mode to interface with FPGA, and have some strange time gaps between burst transfers.

I transfer 1Kb of data from/to SRAM at 0xA000xxxx to/from OCRAM at 0x2020xxxx using DMA engine.

SEMC parameters: sram sync mode, 16 bit, mux A/D, zero all waits, BL=4(->burst16), LC=4(latency).

   // SEMC->SRAMCR0=0x0000F043; ..SRAMCR1=0x00000000; ..SRAMCR2=0x00040000;

DMA transfer size is 32 bytes (it is a maximum, as I can understand).

Clocks: 150MHz SEMC, 150MHz IPG, 600MHz CPU.

As a result, I have timings for 1Kb transfers (and see 2x slow speed than expected):

Up (SEMC => OCRAM): burst16 time 170ns; gap time 170 ns; overall 1Kb time 11us;

Down (OCRAM => SEMC): burst16 time 150ns; gap time 170 ns; overall 1Kb time 10us;

Time diagram inside bursts seems Ok, but what about time between transfers?

The question is: are this time gaps "normal" for iMX1062 chip or I can do something to decrease them?

Sincerely yours Ivan.

[melissa_hunter]

Hi Ivan,

I want to clarify a few things on your settings. You said the DMA transfer size is 32bytes. Is that actually the SSIZE/DSIZE and the overall transfer size (NBYTES) is 1Kb? It might be easiest if you just send me a screenshot showing the DMA TCD registers for the channel you are using. Then I can see the exact configuration you are using. 

It won't help to decrease gaps between transfers, but is using a larger BL within the SEMC an option? Or does the FPGA not support it? For BL=4, I'm expecting 4 beats of 16-bits, so 8bytes per burst. Is this what you are getting? Are you seeing 16byte/8 beat bursts (which is why you are referring to it as burst16)?

Regards,

Melissa

[i_osipov]

Hi, Melissa.

Yes, I see this transfer 1Kb as 32 bursts by 16 words on 16 bit bus. Burst length coding as 4 in BL field of SRAMCR0 means 16 burst length.

I have and attach DMA,SEMC,CCM register logs, DMA used slot #4.

If, as you writing, gaps between transfers are " as-is ", we only can upset about this...

I see the BL field of SEMC.SRMCR0 can be tuned for 32 and 64 burst length - are this values can be actually used in this chip?

(what a process can activate so large transfers - DMA can`t move more then 32 bytes, as I see)

Thank you, Ivan.

[melissa_hunter]

Hi Ivan,

Thanks for the registers, I understand your setup now. For the burst length, I was interpreting BL=4 as field configured for 010b which decodes to 4 instead of set to 100b which decodes to 16. Now that I can see your settings it is clear.

So you already have the SEMC configured for 32byte bursts (16 beats where each beat is 16-bits). The larger burst lengths won't help in your case. If you were using an 8-bit wide bus, then the BL=32 setting could be useful but for a 16-bit wide bus the BL=32 or 64 settings won't help, because as you said there isn't anything in the chip that would request transfers of this size. 

The DMA configuration also looks good (SSIZE and DSIZE both set for 32-bytes). Unfortunately, I don't see anything obvious you can do from a configuration stand-point to speed things up.

Are you using the OCRAM space for any data, code, or stack that the core would be accessing while the DMA is running? The OCRAM is shared, so if the core (or any other masters on the chip) are also running accesses to the OCRAM while the DMA is running, then that could be adding delay (although the fact that you are seeing such a consistent gap between SEMC cycles makes it unlikely this is the case). If the core is accessing the OCRAM while the DMA is running, then you could either move what the core is accessing to a different RAM (to avoid the DMA potentially having to wait to get access to the OCRAM). Another option is to adjust the internal bus priority using the NIC, but the bus priority is only used if both masters are trying to start an access at the same time. If the core is already running an access to the OCRAM when the DMA wants to write to OCRAM, then the DMA does have to wait for the core access to complete (higher priority request won't abort a transaction in progress).

Hope this helps,

Melissa 

[george]

Dear @melissa_hunter,

Excuse me for cutting in,

Your comments are very helpful to us.

We would like to use the RT1175 SEMC to connect to the FPGA with SYNC SRAM non-ADMUX mode.
Our concern is that when reading data from our FPGA, the data length may not be 16 word boundary.

This is a possibility, but please tell me.
If DMA SSIZE/DSIZE = 32byte and SEMC BL<16 beats, How can you expect the SRAM bus cycle to behave?
Will multiple bus cycles be issued?
Or will it trigger a fatal error such as Hard Fault?
What happens when BL>16?

It may be a strange question, but we want to hear your opinion.

BR,
George

[i_osipov]

Thank you very match, Melissa,

I check my process for some concurrency from CPU, but, find nothing...

CPU only waits DMA ready, runs at code addresses 0x0001xxxx ( TCM ) and only accesses DMA0 registers;

Moreover, if I do 32-bit transactions (when I waiting DMA finish) from CPU to FPGA , they "placed inside gaps", practically no increasing overall process time. It seems, DMA engine pauses without any need...

Ivan.

[melissa_hunter]

Hi Ivan,

Unfortunately I think you've done what you can to optimize, so the performance you're getting is it.

Regards,

Melissa

[i_osipov]

Thank you, Melissa.

Best regards,

Ivan

[FelipeGarcia]

Hello Geroge,

The only example we have available is the SEMC example of the MCUXpresso SDK. The sdramc example shows how to use SEMC controller driver to initialize the external SDRAM chip. Please use it for reference.

I hope it helps!

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[g_volokh]

Dear Felipe,

I see a lot of settings in the SEMC according SRAM  sync mode, all of

them are not described.

There are:

- SRAMCR0.COL

- SRAMCR3.RDH

- SRAMCR3.CEITV

- SRAMCR3.RD

- SRAMCR3.WDH

- SRAMCR3.WDS

Can you ask R&D group describe them and give me diagrams to see them?

Thanks in advance.

George Volokh.

[FelipeGarcia]

Hi George,

I am going to ask internally to see if we have some example that we can share. I will let you know if there is any update.

Regards,

Felipe

[g_volokh]

Felipe,

Thanks a lot, it will be very nice.

In other case, it will be too strange to have such powerful chip and not

to have information how to use it.

Thanks in advance,

Regards,

George Volokh.

[FelipeGarcia]

Hi George,

I have received feedback from the applications team and unfortunately, we do not have any SRAM example that we could provide.

I am sorry for the inconvenience that this may cause you.

Regards,

Felipe

[melissa_hunter]

Hi George,

Do you still need help with this? As Felipe stated, we don't have any SRAM examples. I can help you as best I can though (I don't have a board with an SRAM to use for testing). If you do still need help with the SRAM, let me know how far you've gotten and what problems/questions are open.

Regards,

Melissa

[i_osipov]

Hi Melissa,

are the questions about SRAM performance must be started in a new thread?

Or I can join and continue here?

Ivan.

[melissa_hunter]

Hi Ivan,

You can just add your questions to this thread if you want.

Regards,

Melisa

[i_osipov]

Thank your very match, Melissa. I start as a reply to George to remove spare tabs...

[g_volokh]

Melissa,

Thanks again for your very professional support.

We are working with SRAM in synchronous mode (really we connect an FPGA

via this bus).

Everything is working now, but we are trying to speed up the communication.

And, as I know, it doesn't work fast.

I will ask my college Ivan Osipov to connect to you, he is in charge of

this part of our device.

He is in copy.

Thanks and regards,

George Volokh.

[g_volokh]

Dear Felipe,

Really it doesn't help and it was a reason to ask you the question.

SDRAM works nice here, but I can run SRAM using SEMC.

Can you ask your R&D group for an example?

Thanks in advance.

George Volokh.

[g_volokh]

Dear Felipe,

Really it doesn't help and it was a reason to ask you the question.

SDRAM works nice here, but I can run SRAM using SEMC.

Can you ask your R&D group for an example?

Thanks in advance.

George Volokh.