Actions
Forum Thread Details
  • Replies 30 replies
  • Subscribers 59 subscribers
  • Views 3303 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

  • Info on the PRU's seems scarce, they seem to have been used in some of the earlier stuff around OMAP 1 and the AM335x 'Sitara'. I'm still not quite clear on where exactly the Sitara sits, it seems to be vaguely equivalent to some level of OMAP, but I'm unsure if it's OMAP 3 or what. Then there's the DaVinci in there somewhere as well and it seems clear that OMAP/Sitara/DaVinci all use somewhat common building blocks.

     

    Looking at OMAP 4/5 they seem to come with Cortex-M* rather than PRU, looking at TI's Sitara processor list Sitara ARM Processor Products | ARM Processors |Texas Instruments it's not obvious what ones contain PRUs so I don't expect it to be easy to work out what other devices might.

     

    I don't pretend to know what the advantages/disadvantages are for PRU vs Cortex-M* but you could in some ways understand going for a common Cortex-A* with Cortex-M* setup if for no other reason than keeping developers in more familiar territory.

  • in reply to Former Member

    selsinork wrote:

     

    I don't pretend to know what the advantages/disadvantages are for PRU vs Cortex-M* but you could in some ways understand going for a common Cortex-A* with Cortex-M* setup if for no other reason than keeping developers in more familiar territory.

     

    That's a good point.  Even though the PRU instruction set is pretty trivial, it might put some ARM-focused people off having to learn another one.  It doesn't seem a solid objection though, not for something that simple.

     

    A related possibility is that the need to provide dedicated tools to support a different instruction set was weighing on TI's mind, since software support is costly.  The PRU assembler is trivial enough, but the maintenance issues change sharply once C and other compilers enter the picture.  Using internal ARM microcontroller cores eliminates that as an issue.

     

    I haven't yet checked how the two Cortex-M4 cores in OMAP5 interface to the dual Cortex-A15, but hopefully it's a high bandwidth interface.  Here for all bed-time readers' delight is a link to TI's 6105-page OMAP543x Technical Reference Manual.

     

    Morgaine.

Reply
  • in reply to Former Member

    selsinork wrote:

     

    I don't pretend to know what the advantages/disadvantages are for PRU vs Cortex-M* but you could in some ways understand going for a common Cortex-A* with Cortex-M* setup if for no other reason than keeping developers in more familiar territory.

     

    That's a good point.  Even though the PRU instruction set is pretty trivial, it might put some ARM-focused people off having to learn another one.  It doesn't seem a solid objection though, not for something that simple.

     

    A related possibility is that the need to provide dedicated tools to support a different instruction set was weighing on TI's mind, since software support is costly.  The PRU assembler is trivial enough, but the maintenance issues change sharply once C and other compilers enter the picture.  Using internal ARM microcontroller cores eliminates that as an issue.

     

    I haven't yet checked how the two Cortex-M4 cores in OMAP5 interface to the dual Cortex-A15, but hopefully it's a high bandwidth interface.  Here for all bed-time readers' delight is a link to TI's 6105-page OMAP543x Technical Reference Manual.

     

    Morgaine.

Children
  • in reply to morgaine

    Morgaine Dinova wrote:

     

    A related possibility is that the need to provide dedicated tools to support a different instruction set was weighing on TI's mind, since software support is costly.  The PRU assembler is trivial enough, but the maintenance issues change sharply once C and other compilers enter the picture.  Using internal ARM microcontroller cores eliminates that as an issue.

    I wasn't consciously thinking about that, but yes that could make a huge difference. The likelyhood that you can tap into a ready made toolset with no significant investment or support costs needed will no doubt see the beancounters eyes light up image  Even if it's not the correct decision from an engineering standpoint, it could make a lot of sense economically.

  • in reply to morgaine

    Morgaine Dinova wrote:

    Here for all bed-time readers' delight is a link to TI's 6105-page OMAP543x Technical Reference Manual.

    bed time reading ?  The bedside table will collapse under the weight image

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    I haven't yet checked how the two Cortex-M4 cores in OMAP5 interface to the dual Cortex-A15, but hopefully it's a high bandwidth interface.  Here for all bed-time readers' delight is a link to TI's 6105-page OMAP543x Technical Reference Manual.

    Cool!  I had no idea TI had released an OMAP TRM for anything since the BeagleBoard's OMAP 3.  Dual Cortex-A15 -- very nice!  I wonder when (if) there's going to be a BeagleBigDog?

  • in reply to johnbeetem

    In the hope that Jason is working on a big OMAP5 BeagleBone for us, here's a suitably big 1920x1200 block diagram extracted from the TRM:

     

    image

     

    The two Cortex-M4 embedded microcontroller cores are shown at 1 o'clock as the "IPU subsystem", and the pathway to them is shown as 64-bit.  So far, so good! image

     

    Morgaine.

  • in reply to morgaine

    morgaine wrote:

     

    two Cortex-M4 cores in OMAP5 interface to the dual Cortex-A15

     

    A new competitor in the OMAP5 space has just been released by nVidia, the Tegra K1 featuring quad+1 Cortex-A15 CPU cores (the "big.LITTLE" approach) plus 192 GPU cores.  The fact that it's marketed as a mobile device (essentially, meaning tablets) constrains both its power consumption and its price, so it may well appear embedded on an SBC or in non-tablet cased products.

     

    Historically though, nVidia doesn't seem to be getting much market share for its Tegra line.  Perhaps it just pitches them at too high a price to attract OEM interest away from the likes of Allwinner.

     

    Morgaine.

  • in reply to morgaine

    Ah, but two things would actually be interesting about the K1:

    1. no more porting things to OpenGL ES, you have the full OpenGL at your disposal too.

    2. Even though firmly in the binary blob category, nVidia are fairly good at keeping their GPU driver up to date with mainline kernels, no reason to expect different here.

     

    The combination is a SoC that's not stuck on some ancient vendor kernel and can do most anything a x86 desktop can with nothing more than a straight recompile.  Still, it remains to be seen if it'll be used by anyone. If they make the mistake of no SATA, or network-via-USB it'll be a no-hoper for SBC usage even if it does take off for tablets.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    A new competitor in the OMAP5 space has just been released by nVidia, the Tegra K1 featuring quad+1 Cortex-A15 CPU cores (the "big.LITTLE" approach) plus 192 GPU cores.

    Will it be possible to program the GPU, or is this the usual "look but don't touch" GPU nonsense?  ["Das Machine ist nicht für fingerpoken und mittengrabben."]

     

    [Edit: looks like selsinork answered my question.  Oh well, nothing to see here.  I sure hope Parallella is successful!]

  • in reply to johnbeetem

    John Beetem wrote:

    Will it be possible to program the GPU, or is this the usual "look but don't touch" GPU nonsense?  ["Das Machine ist nicht für fingerpoken und mittengrabben."]

    Remains to be seen I suppose, but if the article is to be believed then all of the normal API's that you get with the desktop versions are available, so you get OpenCL for example.  How much use any of that is will obviously depend on exactly what you want to do with it.  Seems likely that you'll get the usual bits like VDPAU as well which means the media player folks will be happy. On a slight tangent, the sunxi folks have produced a PoC VDPAU lib for the Mali GPU on the A10/A20 as well.

     

    So can you do everything you want? Probably not. Can you do the 90% of common things? Probably yes.  Contingent on nVidia supporting the GPU in the same fashion as they do on x86 of course. So what weighs up better, the zero support of most of the gpu's used in SoC's today vs reasonable support within the limits of what they provide?  Time will tell.  If they don't manage to sell any K1's into interesting devices it'll be moot anyway!

  • in reply to johnbeetem

    John Beetem wrote:

     

    Will it be possible to program the GPU, or is this the usual "look but don't touch" GPU nonsense?

     

    It's ARM Holdings' single biggest claim to dumbness that they made their MALI range of GPUs proprietary instead of openly programmable like their ARM CPU cores.  They had a fantastic business model going that created great synergy in the ARM community, and then they turned their brains off and followed the proprietary path that splits their community instead.  (Sure, there's a reason it's closed as they bought in a third party design, but they could have designed their own GPU instead or else negotiated a deal allowing MALI to be open.)

     

    The only good light on the horizon is that the open source Limadriver is reputed (by Olimex) to work well.  The website news hasn't been updated since last March though and their Gitorious repo not since October, so there is room for worry as well.  (Plus the fact that only MALI-2* and MALI-4* seem to be covered for now.)

     

    Morgaine

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    It's ARM Holdings' single biggest claim to dumbness that they made their MALI range of GPUs proprietary instead of openly programmable like their ARM CPU cores.  They had a fantastic business model going that created great synergy in the ARM community, and then they turned their brains off and followed the proprietary path that splits their community instead.  (Sure, there's a reason it's closed as they bought in a third party design, but they could have designed their own GPU instead or else negotiated a deal allowing MALI to be open.)

    I suspect that the primary reason Mali is closed (and perhaps other GPUs as well) is that ARM (etc.) fear that if the details were made public they'd have to fight off myriad [*] frivolous patent lawsuits.  By keeping the details secret is makes it harder for aggressors to troll [*] for alleged violations.  OTOH, ARM doesn't seem to be having a cow about Lima.  Maybe they figure that if some grubby FLOSSers [**] open up Mali then ARM can simply say "oh, that's not really the way we do it so don't bother trying to sue".

     

    All this, of course, slows down Progress of Science and useful Arts, but then what are patents for?  [***]

     

    JMO/IANAL

     

    [*] all puns are intentional.

    [**] humorous reference to how FLOSS advocates are often regarded.

    [***] sarcasm is intentional too.