On 2/7/2017 8:04 PM, ags wrote:
> I'm working on using the PRU for critical signal timing, paired with userland 
> code that loads data into the PRU local memory.
> 
> I've done a lot of research learning about latency wrt local and system 
> resources, L3/4 fabric delays, etc. In each case, I haven't seen any 
> difference 
> in the read/write (load/store from the PRU sense) time (PRU cycles) between 
> the 
> PRU core-specific 8k DRAM and the shared 12k DRAM. I also see that PRU0 can 
> access PRU1's 8k DRAM, and vice versa. So in effect the 8k DRAM is also 
> shared 
> between the two PRU cores. So other than providing more memory than the 8k 
> for 
> each PRU core, why would one use the 12k DRAM?
> 
> [Note: I haven't seen any posts measuring latency of load/store from one PRU 
> core to the other PRU core's DRAM. Could that be the advantage of the 12k 
> shared 
> DRAM - same timing when being accessed by either PRU core? If both cores are 
> accessing either the shared 12k or core-specific 8k DRAM concurrently, would 
> that cause one to stall?]

The available TRM is a bit light on specifics, but I would expect the
8K DRAM for each core is single port memory and is highly likely to
incur wait states if both PRU cores are trying to read from the same
memory bank.  I would expect the 12K shared memory to be at least
2-port (so both PRUs could access it simultaneously without incurring
wait states) and possibly triple ported (so the ARM core could access
the memory without potential wait states).

...and of course 12K is bigger than 8K!  :)

-- 
Charles Steinkuehler
[email protected]

-- 
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/5b30675e-b63a-8571-1085-d1ff0b267306%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to