That makes a lot of sense. Unfortunately, many things that make sense to me ultimately turn out to not be true. Does the definitive answer here lie with Gerald? I wonder if he (still) monitors this group...
Regarding the PRUSS I have many questions. I'm really trying to nail down the timing/latency/determinism of PRU execution and IO. Your work measuring latency of IO and # PRU clocks has been very helpful (Thank you for your posts). Still, I wish for validation of what has been measured with architectural/design detail. Much of the data available (even from TI) seems to be conflicting. On Tuesday, February 7, 2017 at 8:12:08 PM UTC-8, Charles Steinkuehler wrote: > > 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] <javascript:> > -- 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/72ce7f9d-b497-47a8-a353-03ca30d1aa0d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
