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.

AM335x register access speed

Other Parts Discussed in Thread: AM3359

Hello,

Our AM3359 is not performing as fast as we had hoped when accessing certain module registers. 

As an example, we are toggling an GPIO pin as fast as possible in u-boot.

An objdump of the code reads:

...

*((volatile u32*)0x481ac190) = 0x8000; 80128324: e5823190 str r3, [r2, #400] *((volatile u32*)0x481ac194) = 0x8000; 80128328: e5823194 str r3, [r2, #404] *((volatile u32*)0x481ac190) = 0x8000; 8012832c: e5823190 str r3, [r2, #400] *((volatile u32*)0x481ac194) = 0x8000; 80128330: e5823194 str r3, [r2, #404] *((volatile u32*)0x481ac190) = 0x8000; 80128334: e5823190 str r3, [r2, #400] *((volatile u32*)0x481ac194) = 0x8000; 80128338: e5823194 str r3, [r2, #404]

...

Using an oscilloscope, we measure the time between each instruction to 220ns as seen below.

We are having the same problem when accessing the GPMC and the DMTimer modules.

Does anyone have a clue about what we might have configured wrong?

Thanks in advance,

Rickard

  • Hi Rickard,

    Nothing is wrong, these are latencies over the internal interconnects. And I suppose the u-boot environment adds some too.

  • Thank you for your quick response.

    But are we supposed to have that latency also when using the GPMC interface?

    We currently have our GPMC read instruction configured to eleven 100Mhz cyles with the chip select held low for ten cycles.

    We can see the CS going low for exactly 100ns, but between two consecutive reads of the same address, there are an added delay of 270ns.

    This means that each byte takes 380ns to read, which gives us a very slow throughput.

    The GPMC is connected to an FPGA which delivers data on fixed addresses. 

    Regards,

    Rickard

  • I don't know how your GPMC is configured. I know that people on this forum have achieved a lot faster throughput than what you say.

  • Have you seen people achieving higher throughput than we without using DMA?

    In the current implementation we cannot use burst reads or read-ahead since we are alternating between reading a data and a status register at different memory positions.

    Hence we are using single synchronous 1-byte reads with the following configuration.

    WRAPBURST					0
    READMULTIPLE				0
    READTYPE					1
    WRITEMULTIPLE				0
    WRITETYPE					1
    CLKACTIVATIONTIME			0
    ATTACHEDDEVICEPAGELENGTH	0
    WAITREADMONITORING			0
    WAITWRITEMONITORING			0
    WAITMONITORINGTIME			0
    WAITPINSELECT				0
    DEVICESIZE					0
    DEVICETYPE					0
    MUXADDDATA					0
    TIMEPARAGRANULARITY			0
    GPMCFCLKDIVIDER				0
    CSWROFFTIME				3
    CSRDOFFTIME					11
    CSEXTRADELAY				0
    CSONTIME					1
    ADVAADMUXWROFFTIME			0
    ADVAADMUXRDOFFTIME			0
    ADVWROFFTIME				3
    ADVRDOFFTIME				3
    ADVEXTRADELAY				0
    ADVAADMUXONTIME			0
    ADVONTIME					0
    WEOFFTIME					3
    WEEXTRADELAY				0
    WEONTIME					0
    OEAADMUXOFFTIME			0
    OEOFFTIME					11
    OEEXTRADELAY				0
    OEAADMUXONTIME				0
    OEONTIME					0
    PAGEBURSTACCESSTIME		0
    RDACCESSTIME				11
    WRCYCLETIME					3
    RDCYCLETIME					11
    WRACCESSTIME				2
    WRDATAONADMUXBUS			0
    CYCLE2CYCLEDELAY			0
    CYCLE2CYCLESAMECSEN		0
    CYCLE2CYCLEDIFFCSEN			0
    BUSTURNAROUND				0
    

    I cannot see any reason for it to have a such a long latency between two reads other than that we are seeing the same latency as when we do when we are for instance accesing the GPIO.

    I have not seen anyone discussing GPMC speeds when using single reads.

     

    Best regards,

    RIckard