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.

Read cycle timing for AM3517 GPMC

Other Parts Discussed in Thread: AM3517

Hi,

I have one question regarding the read cycle timing of AM3517 GPMC.

The current setting of GPMC configuration registers are the following.

OUTREG32(&pGpmc->GPMC_CONFIG1_2, 0x00001000);

OUTREG32(&pGpmc->GPMC_CONFIG2_2, 0x00181602);

OUTREG32(&pGpmc->GPMC_CONFIG3_2, 0x00010100);

OUTREG32(&pGpmc->GPMC_CONFIG4_2, 0x14061406);

OUTREG32(&pGpmc->GPMC_CONFIG5_2, 0x01141A1C);

OUTREG32(&pGpmc->GPMC_CONFIG7_2, 0x00000F46);

As you know, Config5 register [4:0] bits shows RDCYCLETIME.

Its value is 0x1C(28) as the following.

Bits     Field Name             Type      Value    Note      

4:0    RDCYCLETIME        RW         0x1C    (28)d  

GPMC_FCLK is 166MHz(6.02ns).

In the above setting,  customer checked the  read cycle time.

It is approximately 400ns/cycle.

I think this timing is too long.

Because I think the read cycle timing can be calculated roughly as the below.

GPMC_FCLK * READCYCLE TIME = 6.02 x 28 = 168.56ns

The result of the measurement shows it is 400ns. It is over twice than register setting value.

What is the wrong?

Please give me advise what should I check.

I appreciate your quick reply.

Best regards,

Michi

  • Hi Michi,

    Can you confirm that GPMC_FCLK is 166MHz? Can you post some scope screenshots?

  • Biser-san,

    Thank you for your quick reply.

    Yes, I already confirmed the GPMC_FCLK is 166MHz by using OE signal.

    As you know the setting of OEONTIME is 6, and the setting of OEOFFTIME is 20.

    OE time = 20 -6 =14cycle. And the OE signal duration of the measurement is 85ns.

    So GPMC_FCLK is 6.07ns(85ns/14cycle=6.07ns).

    From this result, GPMC_FCLK is 166MHz.

    Best regards,

    Michi

  • Hi Michi,

    I don't see anything wrong with the timings. The point to investigate here can be how they perform reading from the GPMC. Do they use DMA or just sequential reads? However I'm not a SW expert and cannot comment on this much. There is a good post here, about DMA with the GPMC: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/348712.aspx

  • I assume that the missing 230ns are the internal arbitration times of the busses inside the CPU. These are very typical values.

    Measurement of the *real* read cycle time involves the transfer of a bigger chunk of data, which means that you have to use DMA (or some sort of data caching/flushing inside the CPU).

  • Dear Wolfgang-san,

    Thank you for your useful information.

    You said me " You have to use DMA for solving this issue." But now this system can't use DMA transfer by some customer's circuit issue. So do you have any other idea for shrinking the internal arbitration times?

    I appreciate your quick reply.

    Best regards,

    Michi

  • Michi,

    I do not understand. DMA means; "use the DMA controller inside the CPU to do the data transfer". It has nothing to do with external circuit. You do not need special DMA request/Acknowledge signals.

    Using DMA, you can transfer bigger chunks of data at once, so the bus arbitration will only happen once for each transfer.

    Regards

    Wolfgang

  • Dear Wolfgang-san,

    Thank you for your quick reply.

    In the current circuit of NAND flash,  A0 pin is connected to GND. So customer can not use the odd address as start address of the source. The customer would like to download the OS image to DDR. But some start address of block of OS image is odd address. So customer can not use DMA transfer.  

    Do you have any idea to shrink the internal arbitration except for DMA transfer? 

    I appreciate your support.

    Best regards,

    Michi