4 ms·

NXP's i.MX7 and i.MX8 lines of application SoCs contain Cortex-M4 subprocessors for real-time work. https://www.nxp.com/products/processors-and-microcontroller

NXP's i.MX7 and i.MX8 lines of application SoCs contain Cortex-M4 subprocessors for real-time work. https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-7-processors:IMX7-SERIES https://www.nxp.com/products/processors-and-microcontrollers... https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-8-processors:IMX8-SERIES https://www.nxp.com/products/processors-and-microcontrollers...

zokier 8y ago
How do the M4 and Ax(x) cores communicate? From the block diagram it looks like they are very separate from each other. The neat thing about PRUs is that afaik they also have very high performance connection to the main memory, allowing you to do high-speed IO via them
- kens 8y ago
  (Author here.) One of the inconvenient things about the PRUs is there's a fair bit of latency to access anything outside the PRU. For instance, 34 cycles to access a non-PRU GPIO or 47 cycles to access main (DDR) memory. I've run into problems where I think the PRUs will have plenty of performance, and then these latencies eat up the time budget. http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Late...
  - monocasa 8y ago
    47 cycles to DDR is pretty great though. Big ol' x86/POWER/s390 cores can get close to an order of magnitude farther away to hit the actual of chip DRAM.
    - jws 8y ago
      The PRUs run at 200MHz. So that is something like a 250ns latency, so four times faster than an Apple ][ for RAM access. (Maybe ten times faster, I think all the memory instructions took two cycles or more.)
  - mallets 8y ago
    By access do you mean read or write? I am using that right now and it is just 2 cycles to write (SBBO) and total 8 cycles for it to take effect (the PRU is free to do other stuff after the 2 cycles). Better of reading from the PRU pins though, just 1 cycle. Maybe you can use the other PRU to read from DDR and signal when the data is ready , if using the non PRU pins is the only way to go.
- nudgeee 8y ago
  They communicate via AXI/AHB bus[0] according to the block diagram in the datasheet[1]. [0] https://en.m.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture https://en.m.wikipedia.org/wiki/Advanced_Microcontroller_Bus... [1] https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf
  - zokier 8y ago
    Interesting, I went out and looked more into it and it seems like rpmsg from openamp is the "blessed" way of doing communication between the cores, and they seem to share the memory space with the memory controller sitting on the same bus. Random presentation slides I found on the topic: https://elinux.org/images/3/3b/NOVAK_CERVENKA.pdf https://elinux.org/images/3/3b/NOVAK_CERVENKA.pdf

zokier 8y ago

How do the M4 and Ax(x) cores communicate? From the block diagram it looks like they are very separate from each other. The neat thing about PRUs is that afaik they also have very high performance connection to the main memory, allowing you to do high-speed IO via them

kens 8y ago
(Author here.) One of the inconvenient things about the PRUs is there's a fair bit of latency to access anything outside the PRU. For instance, 34 cycles to access a non-PRU GPIO or 47 cycles to access main (DDR) memory. I've run into problems where I think the PRUs will have plenty of performance, and then these latencies eat up the time budget. http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Late...
- monocasa 8y ago
  47 cycles to DDR is pretty great though. Big ol' x86/POWER/s390 cores can get close to an order of magnitude farther away to hit the actual of chip DRAM.
  - jws 8y ago
    The PRUs run at 200MHz. So that is something like a 250ns latency, so four times faster than an Apple ][ for RAM access. (Maybe ten times faster, I think all the memory instructions took two cycles or more.)
- mallets 8y ago
  By access do you mean read or write? I am using that right now and it is just 2 cycles to write (SBBO) and total 8 cycles for it to take effect (the PRU is free to do other stuff after the 2 cycles). Better of reading from the PRU pins though, just 1 cycle. Maybe you can use the other PRU to read from DDR and signal when the data is ready , if using the non PRU pins is the only way to go.
nudgeee 8y ago
They communicate via AXI/AHB bus[0] according to the block diagram in the datasheet[1]. [0] https://en.m.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture https://en.m.wikipedia.org/wiki/Advanced_Microcontroller_Bus... [1] https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf
- zokier 8y ago
  Interesting, I went out and looked more into it and it seems like rpmsg from openamp is the "blessed" way of doing communication between the cores, and they seem to share the memory space with the memory controller sitting on the same bus. Random presentation slides I found on the topic: https://elinux.org/images/3/3b/NOVAK_CERVENKA.pdf https://elinux.org/images/3/3b/NOVAK_CERVENKA.pdf