• State
  • Replies 2 replies
  • Subscribers 100 subscribers
  • Views 43 views
  • Users 0 members are here
Support feedback
Options
Options
Related

SK-AM62: Excessive Dead Time Between Consecutive U16 GPMC Reads

Victor Chan
Intellectual 775 points
Part Number: SK-AM62

Tool/software:

Hello,

We have the GPMC interface connected to our ASIC via a 16 bit bus with wait acknowledgment. Everything appears to work great except for this one minor issue with excessive time between two U16 reads.

Data transfers that works great are as follows:

When the CPU requests a single U32 read or a U32 write, then the bus has 2 U16 transactions separated by less than 40 ns.

When the CPU requests a U16 write followed by a U16 write, then the bus has 2 U16 transactions separated by less than 50 ns.

The problem is that when the CPU does a U16 read followed by another U16 read, then there is almost 250 ns of dead time between the accesses. Is there any way to improve this? I would expect the CPU to take the approximately the same 50ns separation between the two U16 reads that it would take to do the two separate U16 writes.

Thanks,
Victor

  • 0
    TI__Mastermind 18640 points

    Hello Victor,

    Please help us to understand morte about the GPMC setup.

    What type of memory does your ASIC emulate: a NAND-Flash, NOR-Flash or SRAM memory ?
    What is the 16-bit GPMC access mode you have configured:
    synchronous/asynchronous, multiplexed or non-multiplexed ?
    If multiplexed, Is it an Address/Data multiplexed or a AAD address/address/data multiplexed mode ?
    Are these two consecutive reads - burst reads or two consecutive single reads ?
    Is the WAIT signal (input to GPMC) asserted between the two consecutive 16-bit reads
    Can you show timing oscillograms of the WAIT, REn/OEn, Data0 signals
    Can you dump registers: CS_CS_GPMC_CONFIG1_J_J as per the relevant chipselect
    Can you show dump of registers: CS_CS_GPMC_CONFIG1_J_J ...CS_CS_GPMC_CONFIG7_J_J values for your ASIC-relevant chipselect (index j) during the two consecutive reads ?
    We are interested to know the values of some bitfields like:
    RDACCESSTIME
    RDCYCLETIME
    PAGEBURSTACCESSTIME

    Thanks,

    Stan

  • 0
    TI__Mastermind 30140 points

    Hi Victor,

    This delay between back to back U16 reads is typical of the delay between sequential read requests coming from the CPU. Command latency from CPU to GPMC + GPMC configuration time + Read data latency back to CPU. I've observed this both with R5F and A53 ARM cores. We can see this in simulation of the internal signals and see the CPU issue a read request on the interconnect and wait until the data returns before requesting another CPU read.

    The U32 read has minimal dead time between 2 back to back U16 transactions because it is issued as a single CPU read command on the internal interconnect.

    I'm not too familiar with the specifics of the ARM architecture or compiler... but I suppose its to prevent data hazards in the ARM data pipeline. DMA can get around this latency, but I'm not sure how to force the CPU to issue multiple reads before the first read data appears at the CPU. I will ask internally if there is some optimization or data block like calling asm(" DMB"); between reads... 

    Writes get pipelined/queued and can maximize throughput. You could disable write pipeline with optimization -o2 (to see similar latencies as reads).

    Hope this helps,
    Mark