AM623: GPMC 8-bit or 32-bit Read Access with 16-bit Data Bus Width

Hello ,

I am looking at your queries and you may expect reply by Monday .

Regards,

Anil.

Hi Anil,

Happy new year. Could we have any update on this ?

Thanks and regards,
Hideaki

Hello Anil, 

Did you have a chance to look into the query. 

is there something that need to checked with the GPMC expert.

Regards,

Sreenivasa

Hi Anil,

Two months have passed since original post from Matsumoto-san and the customer complains too late answer for the question. 

Could you answer question ASAP?

Best regards,

Shota Mago

Hideaki-san,

1. I believe byte enable signals only assert during writes and not reads. Let me try to find out why and where it is stated in the documentation.

2. Since the internal connection from ARM core to GPMC uses a 32 bit bus, a 32-bit access arrives at the GPMC as a single VBUS/OCP access.
But with WRITEMULTIPLE and READMULTIPLE both set as single access instead of multiple access, GPMC should not perform a burst (a burst is when an address is given once and 2 or more data access occur sequentially without address between).
Try increasing the value of CYCLE2CYCLESAMECSEN - Chip select high pulse delay between two successive accesses
Also try increasing the value of CYCLE2CYCLEDELAY - Chip select high pulse delay between two successive accesses

Regards,
Mark

Mark,

Do you have any update for #1?

Hi Konishi-san,

I spent some time today researching for #1 and may have a lead. I have asked the designer about and expect to hear back by Monday next week.

Basically, I am trying to understand if this behavior is related to the errata from AM64 SR1.0 i2313 — GPMC: Sub-32-bit read issue with NAND and FPGA/FIFO https://www.ti.com/lit/er/sprz457i/sprz457i.pdf

I want to confirm how the Byte Enable from the VBUS internal interconnect translates to Byte Enable pins BE1n and BE0n during the scenario of 8-bit reads on a 16-bit bus.

Apologize for the slow response here. I will follow up on Monday.

Regards.

Apologies for the delay. We are simulating the design to confirm the behavior and study the byte enable signals inside the GPMC and VBUS interface. If we confirm that byte enables are always driven low for 8-bit reads then we will update the documentation. I feel this outcome is likely based on this previous E2E post. We want to be sure that the compiler or ARM core configuration is not making 8-bit reads look like 16-bit reads.

Assuming byte enables are always driven low during 8-bit reads, I'd like to help to workaround the problem.

How is the customer trying to use the byte enables during an 8-bit read from a 16-bit bus? Why do they need byte enable for 8-bit reads?
Are they reading registers? Are they reading from a memory? Are they shifting data out of a FIFO?

1) Is it possible for the FPGA to respond to the 8-bit read access as a 16-bit read access? The CPU ignores one byte of the 16-bits and performs 2 reads to the same address for 2 8-bit reads.
For example:
a) The CPU reads 8-bits from byte address 0
Address 0 appears on the address bus
Both byte enables go low (even though 8-bit read)
FPGA outputs data from byte address 0 and 1 on both AD[7:0] and AD[15:8]
The CPU reads only the 8-bits of data from the appropriate upper or lower byte
b) The CPU reads another 8-bits from byte address 1
Address 0 appears on the address bus again
Both byte enables go low (even though 8-bit read)
FPGA outputs data from byte address 0 and 1 on both AD[7:0] and AD[15:8]
The CPU reads only the 8-bits of data from the appropriate upper or lower byte


2) If 8-bit data is required, is it possible to configure GPMC in 8-bit data bus mode
DEVICESIZE = 0 (8-bit). Data uses AD[7:0] only and only byte enable 0 toggles low for reads and writes.

Other solutions may be possible. Please describe the system and connectivity to GPMC bus.

We will update with the simulation results by Tuesday.

Hi Konishi-san,

We have confirmed in the design and through simulation that byte enables are asserted low during reads when DEVICETYPE = 0x0 NOR flash-like.
The correct data from the corresponding byte is picked out of the 16-bit data bus.
It was assumed that NOR memory functionality would not be affected by this behavior.
If communicating with an FPGA, then the implementation must be designd to workaround byte enables asserted low during reads.
We will update the documentation in the TRM to describe this behavior during reads from DEVICETYPE = 0x0: NOR flash-like, asynchronous and synchronous devices.
Please let us know how the system meant to use byte enables during reads so we can help to provide a viable solution.

Regards,
Mark