IMXRT1060 and SRAM in synchro mode

cancel
Showing results for 
Search instead for 
Did you mean: 

IMXRT1060 and SRAM in synchro mode

451 Views
Contributor I

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.

0 Kudos
19 Replies

122 Views
Contributor I

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.

0 Kudos

122 Views
NXP Employee
NXP Employee

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

0 Kudos

122 Views
Contributor I

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.

pastedImage_1.png

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.

0 Kudos

122 Views
NXP Employee
NXP Employee

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 

0 Kudos

122 Views
Contributor I

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.

0 Kudos

122 Views
NXP Employee
NXP Employee

Hi Ivan,

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

Regards,

Melissa

0 Kudos

122 Views
Contributor I

Thank you, Melissa.

Best regards,

Ivan

0 Kudos

122 Views
NXP TechSupport
NXP TechSupport

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.
-------------------------------------------------------------------------------

0 Kudos

122 Views
Contributor I

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.

0 Kudos

122 Views
NXP TechSupport
NXP TechSupport

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

0 Kudos

122 Views
Contributor I

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.

0 Kudos

122 Views
NXP TechSupport
NXP TechSupport

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

0 Kudos

122 Views
NXP Employee
NXP Employee

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

0 Kudos

122 Views
Contributor I

Hi Melissa,

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

Or I can join and continue here?

Ivan.

0 Kudos

122 Views
NXP Employee
NXP Employee

Hi Ivan,

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

Regards,

Melisa

0 Kudos

122 Views
Contributor I

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

0 Kudos

122 Views
Contributor I

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.

0 Kudos

122 Views
Contributor I

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.

0 Kudos

122 Views
Contributor I

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.

0 Kudos