• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 172 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM6442: How many PRU clock cycles does PRU assembly instruction SBBO, LBBO cost?

AM2434: LBBO command takes nearly 120ns in PRU when visiting MSRAM (0x70000000)

Jeremy Chen
Prodigy 20 points
Part Number: AM2434

Tool/software:

When I use PRU to read out the memory date , LBBO command cost 120ns, it is too long.

I need my logic to work at a 100ns clock frequency. In each cycle, I need to read data from memory, but LBBO command takes nearly 120ns, which is abnormal. When I use the LBCO command, it only takes 15ns. I think this might be related to the memory address. I'm using the 0x70000000 MSRAM area, writing from R5, and reading via PRU. 120ns seems too long. Is there a way to shorten the time of this command? My PRU works at 200Mhz, with a single - instruction - cycle time of 5ns.

Code:

LBBO &PIXEL_DATA, SHARED_MEM, 0, 2 ;  cost 120ns
MOV r30.w0, PIXEL_DATA

  • 0
    TI__Mastermind 47541 points

    It's not abnormal and expected.

    ICSS internal RAMs, DMEM0 (8KB), DMEM1(8KB) and SMEM (64KB) incurs 15ns latency for LBBO or LBCO.

    MSRAM is better suited for burst access of 32 or 64 bytes, as read penalty remain the same as reading 2 bytes (!) and much faster and does not stall PRUs if you are using XFR2VBUS RD DMA widget in ICSSG.

  • 0 in reply to PratheeshGangadhar
    Prodigy 20 points

    Thanks for your prompt reply.

    In my case, Even reading 64 bytes at a time may not resolve my issue, as I need PRU to read data from the cache and then output approximately 100KB with data cycle 100ns. The sizes of the ICSS internal RAMs, DMEM0 (8KB), DMEM1 (8KB), and SMEM (64KB), are insufficient for my needs. Do you have any suggestions?

  • +1 in reply to Jeremy Chen
    TI__Mastermind 47541 points

    Maybe you can try classic ping pong approach, say split SMEM into 32KB banks and use XFR2VBUS to fetch (using say RTU) to fill second bank while read of first bank ongoing from PRU. But I am not sure whether you can sustain 100KB/100ns => 8Gbps kind of throughput with this approach if it is continuous read...