Sorry, just saw that you actually mentioned that the shared memory has the same performance as the DRAM. Also, I found this: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Load_.2F_Store_Instructions where it is said that LBBO should take (1+word count) cycles. If that's right, an LBBO instruction up to 4 bytes should take 2 cycles for VBUS and 3 cycles for VBUSP. For now I need to study more to understand which one is the case, but VBUSP matches with your findings.
Em sexta-feira, 3 de janeiro de 2014 23:05:30 UTC-2, Lenny escreveu: > > Hello, > > I am using a Beaglebone Black. When i measured the number of PRU clock > cycles needed for the execution of various assembler instructions, I found > surprisingly large values for memory access. Here follows a list, in which > one cycle corresponds to a delay of 5ns as expected: > > Most operations, such as ADD,SUB,QBxx,MOV,JMP etc.: 1 cycle > > LBBO 1,2,4 Bytes from PRU DRAM: 3 cycles > LBBO 8 Bytes from PRU DRAM: 4 cycles > LBBO 12 Bytes from PRU DRAM: 5 cycles > LBBO 16 Bytes from PRU DRAM: 6 cycles > > LBCO 4 Bytes from DDR: 43 cycles > LBCO 8 Bytes from DDR: 44 cycles > LBCO 12 Bytes from DDR: 45 cycles > LBCO 16 Bytes from DDR: 46 cycles > > With PRU DRAM, i mean any addresses between 0x00000000 and 0x00004000 and > the shared PRU RAM (12 kB starting from 0x00010000). Any other address i > tried had the delay stated for "DDR". > > 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? > > Thanks in advance! Lenny > -- 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/d/optout.
