This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[OMAP3530] Problem about delay between two successive read accesses

Hi all,

I try to find why delay between two successive read accesses is fixed at 180ns when GPMC clock at about 120 MHz and successive delay at gmpc GPMC_CONFIG6_i is set to 0.

The parameter setting for gpmc is bellow:

GPMC_CONFIG_xy                  0x6E000050
        bit1:0                                   for no Limited Address device

GPMC_CONFIG1_4                 0x6E000060 + (0x00000030 * 4)
        bit30:0x0                             READMULTIPLE for Single Access
        bit29:0x1                             READTYPE for Read Asynchronous
        bit26~25:0x0                      CLKACTIVATIONTIME for First rising edge of GPMC_CLK at start access time
        bit24~23:0x0                      ATTACHEDDEVICEPAGE LENGTH for 4 Words
        bit22:0x0                             WAITREADMONITORING for Wait pin is not monitored for read accesses
        bit13~12:0x1                      DEVICESIZE for 16 bit
        bit11~10:0x0                      DEVICETYPE for NOR Flash like, asynchronous and synchronous devices
        bit9:0x1                               MUXADDDATA for Address and data multiplexed attached device
        bit4:0x0                               TIMEPARAGRANULARITY for x1 latencies
        bit1~0:0x0                          GPMCFCLKDIVIDER for GPMC_CLK frequency = GPMC_FCLK frequency

GPMC_CONFIG2_4                 0x6E000064 + (0x00000030 * 4)
        bit12~8:0x7                        CSRDOFFTIME for 7 GPMC_FCLK cycle
        bit7:0x0                               CSEXTRADELAY for CS I Timing control signal is not delayed
        bit3~0:0x1                          CSONTIME for 1 GPMC_FCLK cycle

GPMC_CONFIG3_4                  0x6E000068 + (0x00000030 * 4)
        bit12~8:0x5                          ADVRDOFFTIME for 5 GPMC_FCLK cycle
        bit7:0x0                                 ADVEXTRADELAY for CS I Timing control signal is not delayed
        bit3~0:0x2                            ADVRDOFFTIME for 2 GPMC_FCLK cycle
       
GPMC_CONFIG4_4                  0x6E00006C + (0x00000030 * 4)
        bit12~8:0x7                         OEOFFTIME for 7 GPMC_FCLK cycle
        bit7:0x0                                OEEXTRADELAY for CS I Timing control signal is not delayed
        bit3~0:0x4                           OEONTIME for 4 GPMC_FCLK cycle            
       
GPMC_CONFIG5_4                  0x6E000070 + (0x00000030 * 4)
        bit27~24:0x1                       PAGEBURSTACCESSTIME for 1 GPMC_FCLK cycle 
        bit20~16:0x5                       RDACCESSTIME for 5 GPMC_FCLK cycle 
        bit4~0:0x7                            RDCYCLETIME for 7 GPMC_FCLK cycle

GPMC_CONFIG6_4                  0x6E000074 + (0x00000030 * 4)
        bit11~8:0x0                         CYCLE2CYCLEDELAY for 0 GPMC_FCLK cycle      
        bit7:0x0                                CYCLE2CYCLESAMECSEN for No delay between the two accesses
        bit6:0x0                                CYCLE2CYCLEDIFFCSEN for No delay between the two accesses
        bit3~0:0x2                            BUSTURNAROUND for 2 GPMC_FCLK cycles

GPMC_CONFIG7_4                  0x6E000078 + (0x00000030 * 4)
        bit6:0x1                                CSVALID for CS enabled

CONTROL_PADCONF_GPMC_NCS7       0x480020BC
        bit24:0x1                              INPUTENABLE1 for looped-back GMPC_CLK requirement at section 11.1.3.2.1 

 

              

 

From figure, The time delay between a and b is fixed.

I want to reduce the delay. But even though I set the read cycle 3 clock, the gpmc clock nums is reduced according to my setting , the delay between is remain.

It seems that  the delay between is left for max burst word clock, so if you don't use burst. The delay is still left for no use.

Is there any suggestion for me?

  • Dear Jinhu,

    I was searching around the Internet and came across this message you posted. I'm facing exactly the same problem with delay in between two successive asynchronous reads. Did you manage to find the solution and get around it? Your reply will be appreciated. Thanks.

    Regards,

    Aji

  • Check out this thread:

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/43106.aspx

    Short answer is to use DMA or at a minimum you might need to enable cache to that memory range.

  • Hi Brad,

    Thanks for your reply.

    I'm currently implementing the DMA transfer.

    In view of caching, I don't think it's suitable for the device that I'm working on, as I'm not connecting an external memory device to GPMC, but rather an Ethernet switch; therefore, every read operation should physically retrieve the value from the device.

    Another thing that concerns me is that the Ethernet switch device does not support burst read/write. It only support asynchronous single read/write (ISA-like protocol). That's why the delay is really a huge concern. Will DMA solve this?

    Thanks a bunch.

    Regards,

    Aji

  • Aji Gerdiman said:
    That's why the delay is really a huge concern. Will DMA solve this?

    I think so.  It should make a big difference.

  • Hi Brad,

    Thanks for you prompt reply.

    I'm currently having a problem setting up the DMA transfer and still debugging on it. I got this error message "DMA transaction error with device 4"

    About the delay between 2 back-to-back asynchronous PIO reads, is this an inherent characteristic of GPMC? I'm just speculating here, but is there anyway to get around this without DMA?

    Again, thanks.

    Regards,

    Aji

  • Aji Gerdiman said:
    I'm currently having a problem setting up the DMA transfer and still debugging on it. I got this error message "DMA transaction error with device 4"

    I recommend starting a thread for this issue as it is much different than the subject.

    Aji Gerdiman said:
    About the delay between 2 back-to-back asynchronous PIO reads, is this an inherent characteristic of GPMC? I'm just speculating here, but is there anyway to get around this without DMA?

    It is an issue inherent to pretty much every CPU.  When a CPU reads data it has to wait for that data to arrive before it can continue executing instructions.  So even if you have a bunch of read instructions in a row you will be stalled in between and that's my guess where the big delay comes from.  I made a comment about cache, because if cache was turned on the CPU would wait to get that one piece of data but the cache controller would pull in an entire cache line worth of data which would help the performance considerably.  The best option though is DMA.