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.

AM6442: Make sure PRU wins Arbitration

Part Number: AM6442

I am working on an application where I need the PRU to read DRAM0 but I need to know exactly how many cycles the LBBO instruction takes; every time no matter what.

In order to do this, I need to make sure if any other cores are writing to DRAM0, that the PRU always wins arbitration so the number of clock cycles stays constant.

From this E2E post, the PRU engineer mentions a way to make sure the PRU wins arbitration every time it tries to read DRAM0.

"If you want to completely avoid arbitration delay, you could program the non-PRU core to perform multiple 4 Byte writes instead of a single long write. In that case, the PRU would win arbitration every clock cycle it initiates a read. "

From my understanding, if the R5F is writing to DRAM using the following API, then because each individual write is < 4bytes, whenever the PRU tries to read DRAM, it will win arbitration.

I understand winning arbitration means the R5F will pause during the four-byte write, and PRU will read the memory, then R5F will finish writing the remaing bytes from the write call?

R5F API Call: HW_WR_REG16(0x30000000 + OFFSET, VALUE);

 

  • WARNING FOR FUTURE READERS: INFORMATION IN THIS RESPONSE IS NOT GUARANTEED TO BE CORRECT. I AM STILL IN THE PROCESS OF FIGURING THIS INFORMATION OUT MYSELF. SOME DETAILS MIGHT BE WRONG. FEEL FREE TO CREATE A NEW E2E POST ASKING FOR UPDATES IF WE DO NOT PROVIDE A CONCLUSIVE SOLUTION LATER ON IN THIS THREAD.

    Hello Darren,

    Good question. Let me respond with my current understanding, and I will double-check with the hardware designer.

    FYI: hardware validation is a work-in-progress

    I am working with another teammate to validate all the information presented in this FAQ, fix any issues, and then update the PRU Read Latency app note, along with posting the test code to the OpenPRU repo:
    [FAQ] PRU: How do I calculate read and write latencies? 

    First we'll test individual reads, then I want to test arbitration delay. The arbitration delay will probably need to go into a separate document. Unfortunately I am not sure if we will have bandwidth to get to the arbitration tests in the month of March.

    If you are interested in reviewing test code, or if you want to take our test code and then use it to write your own arbitration tests, let me know. I am more than happy to collaborate with you on this effort.

    Ok, so what is the current understanding? 

    First off, the information in that FAQ about the internal bus architecture is not quite correct. Unfortunately there isn't better documentation anywhere, so I have already been going through the actual internal hardware design bit by bit with the developer. Hopefully I will have more information next week. For now, I am considering everything a hypothesis until it has been experimentally verified.

    First off, I do NOT expect the R5F core itself to actually pause execution, if R5F works the same way PRU does (I am not an R5/RTOS expert, so I could be wrong). At least on PRU, writes are fire-and-forget. There CAN still be small arbitration delays for writes (e.g., two different cores writing to the same output port, or XFR2VBUS accelerator and PRU core writing to the same output port) But as soon as the write has exited the PRU subsystem, PRU execution continues, regardless of how long it takes for the PRU data to make it through the system busses and land in the target memory.

    So with that said, your understanding is also my current understanding - if R5F data is queued up in the PRU Subsystem's internal CBASS (VBUSP architecture), and the data from the R5F tries to hit the DMEM0 at the same time as one of the PRU cores tries to read or write to DMEM0, then the PRU cores (ALL of the PRU cores) should be able to take priority over an access from outside of the PRU subsystem. The R5F data should pause in the bus until after the PRU finishes execution, and then get pushed to DMEM0 afterwards.

    Regards,

    Nick

  • Hello there,

    Wanted to provide an update. I am rewriting the FAQ listed above as 2 separate FAQs. 

    The FAQ on read/write latencies is here:
    [FAQ] PRU Read & Write Latencies

    Most of the content is unchanged, though I added information about how XFR2VBUS works.

    The FAQ on arbitration delay is here:

     [FAQ] PRU Arbitration Delay 

    I am fairly confident in this version of the block diagrams, but I still need to verify the priority ranking within the PRU Subsystem's internal CBASS. Right now, it tentatively looks like PRU and TX_PRU cores would be higher priority than the external read, but the RTU cores would be LOWER priority than the external read. Still verifying, please ping the thread on Monday if I have not provided a firm response on that.

    Regards,

    Nick