Actions
Forum Thread Details
  • Replies 30 replies
  • Subscribers 59 subscribers
  • Views 3317 views
  • Users 0 members are here
Related

The future of PRU in TI's SoC evolution

morgaine

The video in Drew's recent blog post about "Maker Mom to demo BeagleBone Black on Chicago's WGN TV morning news" showed the BBB doing what it does so well, fast realtime I/O without CPU intervention, courtesy of its remarkable twin PRUs (Programmable Real-time Units).

 

We've had a lot of discussions about the PRUs on this forum, but that blog got me thinking about their future, how they could be developed further.  There is always room for hardware improvements, more local memory per PRU being clearly desirable and a speed increment always being welcome.  On the software front there are many improvements that could be done in terms of flexible drivers and language support to bring the PRUs into the solution space for more people.

 

Unfortunately, speculating on the bright future possibilities for PRUs then brought to mind a very grim possibility:  that PRUs are seen by TI marketing and product designers not as the exceptional hardware feature and product differentiators that they are, but as irrelevant to future product lines "because nobody is asking for them" or because "nobody else is doing that".  If PRUs were discontinued from TI's future application processor lineup, it wouldn't be the first time that awesome engineering has been scuppered by blinkered business decisions.

 

So, I'll end with some questions and a suggestion:

 

  • If anyone here knows TI's SoC offerings beyond Cortex-A8, did you see PRUs featured in the hardware?  If so, are the PRUs the same as in the BBB's AM3359, or have they evolved further?  Has TI released any relevant information on this issue?
  • Since Drew is in regular contact with Jason Kridner, and perhaps other Element14 staff have knowledge of TI future offerings on a business level as well, could you perhaps inquire for us whether TI's plan is to continue to offer PRUs in future SoCs, or to discontinue the concept, or "no comment" for business reasons, or are they genuinely undecided?

 

From a customer perspective, PRUs can be a very good reason for buying AM335x, but forward-looking engineering decisions involve the existence of a future migration path as well.  If PRUs are end-of-life beyond TI's Cortex-A8-based family, then they're no longer a very appealing feature because not many people are willing to invest much time and effort in a powerful solution that has no future.  I think this is an important question to ask of TI.

 

Morgaine.

Parents

  • I came across something interesting recently that's rather relevant to us discussing the merits of using some Cortex-M* cores in place of the PRUs.

     

    It seems that the am33xx series already has a Cortex-M3 in it. I'm not sure it's terribly useful, it's seemingly used as some part of the power management capabilities and has some sort of hardware mailbox interface to the main cpu.

     

    Documentation and firmware for it is here http://arago-project.org/git/projects/?p=am33x-cm3.git;a=tree

  • in reply to Former Member

    selsinork wrote:

     

    It seems that the am33xx series already has a Cortex-M3 in it. I'm not sure it's terribly useful, it's seemingly used as some part of the power management capabilities and has some sort of hardware mailbox interface to the main cpu.

     

    I guess the appropriate hipster comment would be "Hack all the cores!"  Yep, even that one. image

     

    As an aside, back when we discovered that OMAP5 has replaced the two PRUs of AM335x with two Cortex-M4, it did occur to me that if they'd dedicated the same number of gates to adding more PRUs instead, OMAP5 would have its own integrated array-of-cores, a bit like Parallella. image

     

    Morgaine.

  • in reply to morgaine

    I think it's fairly clear that TI have little interest in the PRU, so even if they had done that without some commitment to active support it I think it would have been pointless.

    What's becoming painfully clear to me is that the boards/SoCs with an active developer community, not 'user' community, are making much more progress. With little in the way of developer community behind the beaglebone and no interest from TI, what future for the PRU ?

  • in reply to Former Member

    selsinork wrote:

     

    I think it's fairly clear that TI have little interest in the PRU, so even if they had done that without some commitment to active support it I think it would have been pointless.

    What's becoming painfully clear to me is that the boards/SoCs with an active developer community, not 'user' community, are making much more progress. With little in the way of developer community behind the beaglebone and no interest from TI, what future for the PRU ?

    I haven't looked into PRU in great detail, but the first impression it made on me is that it's a user/developer-programmable version of the internal RISC processor in Freescale's QUICC communications SoCs.  I've had a lot of experience with various generations of QUICC, and they do support many communications protocols like HDLC, ATM, and async HDLC.  However, the QUICC internal RISC processor is a closed architecture: you can download binary blobs, but you can't write your own.

     

    So I see PRU having the advantage of programmability.  That said, I don't personally have an application for it at this time, and I don't know whether TI is taking any embedded communications sockets away from Freescale.  It may depend on whether EtherCAT takes off and who supports it -- I haven't looked into that either.

Reply
  • in reply to Former Member

    selsinork wrote:

     

    I think it's fairly clear that TI have little interest in the PRU, so even if they had done that without some commitment to active support it I think it would have been pointless.

    What's becoming painfully clear to me is that the boards/SoCs with an active developer community, not 'user' community, are making much more progress. With little in the way of developer community behind the beaglebone and no interest from TI, what future for the PRU ?

    I haven't looked into PRU in great detail, but the first impression it made on me is that it's a user/developer-programmable version of the internal RISC processor in Freescale's QUICC communications SoCs.  I've had a lot of experience with various generations of QUICC, and they do support many communications protocols like HDLC, ATM, and async HDLC.  However, the QUICC internal RISC processor is a closed architecture: you can download binary blobs, but you can't write your own.

     

    So I see PRU having the advantage of programmability.  That said, I don't personally have an application for it at this time, and I don't know whether TI is taking any embedded communications sockets away from Freescale.  It may depend on whether EtherCAT takes off and who supports it -- I haven't looked into that either.

Children
No Data