On 1/3/2014 7:05 PM, Lenny wrote: > > Can anybody confirm the long DDR (and other delays if possible) readout > times that I have measured? Does anybody have an explanation for these > large delays?
Yes, I did some testing of the read and write latency to GPIO pins, the results are in my PRU source code for LinuxCNC: https://github.com/cdsteinkuehler/linuxcnc/blob/MachineKit-ubc/src/hal/drivers/hal_pru_generic/pru_generic.p#L135 The write latency is caused by interfacing to the chip interconnect fabric instead of the local PRU resources. Note that the fabric includes write posting, so if you're not saturating the fabric you can do a write in two PRU cycles (10 nS). If you are saturating the fabric, the maximum rate is 8 PRU cycles (40 nS). For reads, the PRU stalls until the data is returned by the chip interconnect fabric, which takes around 33 PRU cycles (165 nS) when reading from the GPIO ports. If you are actually reading from DDR memory (instead of on-chip resources), you also have the DRAM read latency on top of this. Note that almost all of these values include one or more clock synchronization delays so they can change some either way (shorter or longer) based on clock phasing and configured operating frequencies. -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
