Possibilities to overcome EMIF#4 errata

Why do you need overcome EMIF#4 errata for 16-bit static RAM with DQM?
Problem is additional WE pulse, but without corresponding DQM. And your RAM use DQM (UB and LB). This mean, that extra WE is ignored in RAM chip.

We are using 16bit SRAM and MRAM in normal mode without problem (I hope :-) ). Or I Miss something significant?

PS: CORTEX-R4#66 is worst, it not have simple workaround.

On our side I can confirm that this is NOT working at all.

As soon as we switch to 'normal memory' type, the external SRAM's data content gets corrupted.
Raising the wait states doesn't change anything in this case.

By the way: Our complete code base is compiled with the --no_stm option.

It is strange. You can read on EMIF#4 erreta this sentence: "The byte enable signals (EMIF_nDQM) are not asserted for the extra write pulse."
And compare it to page 4 of your memory chip. UB=H and LB=H mean "output disabled" state, not write. It looks like something else, than this bug.

We are using SRAM Renesas R1LV3216R with DRACR = ((U32)MPU_PRIV_RW_USER_RW_NOEXEC | (U32)MPU_NORMAL_OIWBNOWA_SHARED) setting. Without problem.

PS: we don't use --no-stm, simply because we are not use CCS and TI compiler.

Michael,

Would you please share some details about your concern in performance when the external memory is configured as "device"?

Thanks and regards,

Zhaohong

Hey Zhaohong,

well, that's quite easy.
Due to the fact that the EMIF on this device (TMS570LS3137) has a really insane lag of 30 ns in read direction we have a huge bottleneck here. Because of this we're highly interested in speeding it up as good as we can.

Address ranges configured as 'device type' are treated like peripherals by the processor. This is not good for real memory as it prohibits a lot of optimizations like speculative reads, etc.

Regards,
Michael

Hey Guys,

do you have any news on this?

What I would be most interested in is, if either something else is going mad which prevents the 'normal memory' type working over the EMIF or if the errata is not fully correct and the 'normal memory' type isn't working at all with this interface.

I doubt that it is just a software issue on our side.

We're using compiler version 5.1.6 (in case this has any influence). The RAMs speed grade is 10 ns.

Do you need any additional information for further analysis?

Regards,
Michael

Michael,

I am not aware of any method to remove this restriction. I would suggest you using DMA if big block of data needs to be moved to/from external memory.

Thanks and regards,

Zhaohong

Zhaohong,

please correct me, if I'm wrong.

Is the issue I described actually not caused by EMIF#4, but instead caused by the following errata?

DEVICE#B064 — Incorrect Write to External Memory using Store-Multiple (STMxx) CPU instruction

The text in the errata is quite confusing. It states:
"Only use STR instructions to EMIF with the external memory configured as strongly ordered or device (not normal) type for write operations."

So what about normal memory type then?

Is there any change with silicon rev. D?

Regards,
Michael

Still no update here?

Just as a summary:

Problem #1:
The EMIF has a lag in read direction which adds a 30 ns delay to each and every read transaction.
No errata is existent on this even though it makes the interface almost unusable for more often used data.
In our case, writing is twice the speed compared to reading. How weird is that?
Will this be fixed with silicon revision D?

Problem #2:
Burst writes (e.g. with STM) can cause a processor deadlock and/or data corruption.
As a workaround the --no_stm option shall be used. This should be fixed with silicon revision D.

Problem #3:
Normal device memory type leads to data corruption in conjunction with the EMIF.
The reason for this and/or an according errata issue is pretty much unknown as far as I see.
Will this be fixed with silicon revision D?

Please give me answers.
Thanks a lot in advance.

Regards,
Michael

Hi Michael,

My understanding of the EMIF and DEVICE#B064 is, that this is related to burst accesses not only STM instructions.
This would mean, that if you configure the EMIF region to be Normal type of memory the CPU's write buffer could potentially merge any adjacent writes and thus would cause burst accesses even if no STM instructions are used.

Zhaohong,

Could you please confirm or negate my assumption.

Thanks,
Christian

Michael,

That is right: multiple writes to "normal" memory could be buffered and then merged into a burst write operation which appears just as an STM instruction execution outside the CPU. This is why single writes to normal-type memory are not allowed.

This issue is addressed in RM48 rev D silicon, so that burst writes to external memory are possible.

Regards, Sunil

Sunil,

okay. That are good news.
So this means that from revision D on, any kind of burst write transaction should work on EMIF devices independent of their memory type (except EMIF_nDQM are not used)?

Do you also know if the 30 ns lag will get reduced with Rev. D?

Regards,
Michael

Michael,

There will still be the issue of an extra nWE pulse when writing to external memory. This can be worked around by configuring the external memory as device type. This way you can still employ the CPU's built-in write-buffer and optimize the CPU bandwidth.

Can you clarify what this 30ns lag is? I looked in this thread for information but could not find it.

Regards,
Sunil

Sunil,

got it. So if the external device is using the EMIF_nDQM pins, the additional nWE shouldn't hurt anything...

Regarding the timing:
Just take a look at
www.ti.com/.../spns162
Chapter '6.14.2.1 Asynchronous RAM', Timing NO. 12

Timing #12 states, that during read operation, the data on the data bus needs to be in a stable state for a duration of at least 30 ns before the data can be taken. From my point of view this looks like an implementation accident, considering that a typical asynchronous SRAM is many times faster than that.

Regards,
Michael

Michael,

Let me look into this and get back to you.

Regards,
Sunil

Sunil,

have you already been able to figure out if the read lag has been fixed?

Regards,
Michael

Michael,

There is no silicon update available/planned to "fix" this 30ns additional setup time. However, I am trying to see if this specification can be tightened a bit to hopefully reduce the impact on the choices of asynchronous memories that you can interface to the RM48x MCUx.

Regards,
Sunil

Sunil,

have you already been able to figure out, what you mentioned in your last message?

Regards,
Michael

Michael,

It is taking longer than I expected to get confirmations from the design and test engineering teams. For now, I would assume that there isn't any slack in the specifications listed in the datasheet, so that the additional 30ns is valid. We will revise the datasheets if we identify and confirm any slack in these timings.

Regards,
Sunil

Sunil,

please understand that this topic is very important for us. It's somehow confusing that the original data sheet (see attached file) specified the setup delay (EMIF timing no. 12) to be 3 ns, whereas the newer data sheets specify 30 ns.

It would be very disappointing if there hasn't been any work spent on improving this issue.

Regards,
Michael

3365.spns162.pdf

Sunil,

do you have any (hopefully good) news on this issue?

Thanks in advance.

Regards,
Michael

Hi Michael,

The timings characterization data does not indicate that this setup time could be reduced from the specified 30ns.

Regards,
Sunil