EMIF16 Read Hold Period

Hi Kevin,

You seem to be interspersing reads and writes in the capture shown above. How are you accessing the EMIF? Have you taken into account the internal delays associated with your code executing?

Regards, Bill

I am accessing the EMIF16 by either reading from or writing to the EMIF16 memory space. Using chip select 3, "DEAD" is a read of adress 0x7C000000.

The delays  are not being caused by executing code. I included the writes to demonstrate that they are working per the EMIF16 specification. If I do multiple reads in a "tight" loop, I always get a 24 EMIF cycle delay between reads. The attached image shows four consecutive reads and one write in a tight loop. There is negligible execution delay when the loop rolls over.

Before I disabled the unused internal EMIF feature (*(Uint32*)0x20C00008 |= 0x80000000; ) , I was seeing similar delays between writes.

Hi Kevin,

As I've stated in other posts, the settings for hold, strobe & setup do not define the throughput of the EMIF16. They only define the clocks for each individual access. Additional clocks between accesses are not unexpected. The EMIF16 was not defined as a high speed data interface and was originally envisioned a flash interface for booting. It is also an asynchronous interface which requires extra states to insure that the data is captured correctly for read accesses. Simple reads and writes are the slowest method of accessing the external memory space. Have you attempted to set up a DMA transfer?

Regards, Bill

Hi Kevin,

As I've stated in other posts, the settings for hold, strobe & setup do not define the throughput of the EMIF16. They only define the clocks for each individual access. I understand. All I am asking is that the EMIF16 time delays function as advertised and I will worry about the throughput. I would expect that the programmable read times would behave in the exact same manner as the writes . The write times did not function properly until "the unused EMIF feature" was disabled. I am experiencing a read_hold delay of 24 EMIF cycles (~ 144 nS). I have complete control over the W_HOLD period . I would expect the same for R_HOLD.

Have you attempted to set up a DMA transfer? Not yet. I am not sure how that would help out in this situation.

Hi Kevin,

You do have complete control over the R_HOLD period. If you set the R_HOLD value to 0, I guarantee that you will always have one EMIF clock period between the rising edge of RE and the end of the read access. I cannot guarantee that the turnaround period between the end of one read access and the beginning of the next read access will be zero. You will find that accessing the EMIF in different ways will vary the length of the turnaround between accesses. If you do a 32bit read from address 0x7c000000, you should see a read from external address 0x0 followed by a second read from 0x1 with less turnaround. However you access the EMIF, we do not have a defined number of clocks between accesses.

Regards, Bill

You do have complete control over the R_HOLD period. If you set the R_HOLD value to 0, I guarantee that you will always have one EMIF clock period between the rising edge of RE and the end of the read access. I cannot guarantee that the turnaround period between the end of one read access and the beginning of the next read access will be zero

I don't know how to say this more clearly: changing the R_HOLD parameter has no effect. Regardless of the value that it is programmed with, there is always a 24 EMIF cycle delay between reads. that's pretty significant and I believe that I should be able to program this value and see the results in the logic analyzer per the EMIF16 specification.

Let me re-iterate, the WRITE delay parameters are working fine. However, they were behaving in the same manner until I disabled the "unused EMIF feature" (undocumented bit in an undocumented register).

Why doesn't the R_HOLD period exhibit the same behavior as the W_HOLD? It should. I am wondering if there is another "unused" EMIF feature that needs to be disabled.

 If you do a 32bit read from address 0x7c000000, you should see a read from external address 0x0 followed by a second read from 0x1 with less turnaround. However you access the EMIF, we do not have a defined number of clocks between accesses.

I am pretty sure that when I did a 32-bit access, the 24 cycle EMIF delay was still present between the read of 0x0 followed by 0x1. I will re-test when I have a chance.

Hi Kevin,

I think we're miscommunicating. I've based the drawing below on the settings that you've provided and the diagram in the post. You've set the R_HOLD to 0b101 which will give you six clocks of hold after the OE goes high. This is difficult to see external to the device since you have set select strobe equal to 1. If you had select strobe equal to 0 then you would see the CS terminate at the end of the R_HOLD period. I've shown the address transitioning to an unknown state since it is not guaranteed between the end of R_HOLD to the beginning of R_STROBE. Normally the address will remain static with the last value on the bus. Between the two reads there are additional clocks. These clocks are not defined by the R_HOLD and cannot be controlled. These are based on internal delays within the device and are not defined in the documentation. 

Regards, Bill

OK.

So it sounds like there is no way to get rid of the 24 "turnaround between access" cycles after a read access, this is basically how the interface functions?

Is there a reason that the "turn around between access cycles" after a write access are substantially less than that for a read?

Excuse me, Kevin

could you teaching me about setting EDMA3 transfer?

I don't khow about this.

Hi Taeyang,
There are EDMA examples in the MCSDK release of software supporting this SOC. There is not specific a example of EDMA to the EMIF interface but you should be able to substitute the EMIF address for the LL2 or MSMC address in one of the examples.
Regards,
Bill

Hi Bill,

I am using EVM C6678.

I searched "edma3_drv_bios6_c6678_st_sample" example project.

Where is  setting up an EDMA3CC1?

Shoud I modify this?