On Thu, Feb 9, 2017 at 4:20 PM, ags <[email protected]> wrote:

> Continued review of documentation has caused me to wonder if I've missed a
> fundamental error in my thinking about what is and isn't deterministic when
> using the PRUs. The PRU-local 32-bit interconnect bus is itself a shared
> resource. If one PRU writes to its own DRAM, and the other PRU writes to
> its own DRAM, won't that potentially cause one to stall waiting for the
> other to complete (particularly with a burst load/store)? That would make
> the dual/triple porting of the shared DRAM also less valuable. If the PRUs
> are being used to get data from the ARM core/main memory and then bit bang
> pins, that too is subject to competition for control of the 32-bit bus.
> Does this make sense or am I still missing something?`
>

What is it that you're asking ? There is no "shared DRAM". There is only
"the DRAM" that is used by the main ARM processor, which the PRU's can
access through the interconnect which you speak of. Writing to, and reading
from the DRAM as I understand it is not deterministic. e.g. the L4
interconnect can incur a latency penalty.

However, the 8k memory used by each PRU core, as well as the shared 12k
memory each PRU has access to is supposed to be single cycle read / write
access. In fact each PRU core as I understand it has the ability to
"broadside" all of it's 32bit registers in a single cycle over to the 12k
shared memory.

Now, if you're looking for a way to move data out of the PRU's memory,
maybe having a userspace mmap(), and /dev/mem/ application read directly
from the 12k PRU shared RAM ? You're going to incur a penalty one way or
another. No need to bog down the PRU's trying to solve that problem. What
do you think Charles ? Is this reasonable ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqHv%2B31Y3cmWud0Rv%2BbDFhzkFKy7CdykirL7EjAx01W4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to