Session:Are we headed for a complexity apocalypse for embedded SoCs ELCE 2012

Revision as of 21:13, 12 August 2013 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Session Details

ELC Europe 2012
Matt Locke
Texas Instruments
(not available yet)
(not available yet)
approx. 40 minutes


Hear from Matt Locke, the Director of the Linux Developer Center at Texas Instruments (TI) on the future of embedded SoCs.


Matthew Locke is the Director, Linux Developer Center for Texas Instruments (TI). He is also on the Board of Directors for LInaro and the Heterogenous System Architecture Foundation (HSAF). Matt has more than 15 years experience in technical and business leadership roles in companies building product based on Open Source Software including Mentor Graphics, Embedded Alley and Montavista Software. After Mentor Graphics acquired Embedded Alley, he was Director of Technology for Mentor Graphics Embedded Software Division where he led their strategy and product development for Linux and Android development environments. He was COO of Embedded Alley which provided services and technology based on embedded Linux to leading consumer, mobile and networking OEMs. Matthew Locke has a Bachelor of Science, Electrical Engineering from University of Maryland, College Park.


See below for detailed notes of this talk.


Transcribed by
Verified by
1 -

0:00 - 1:00:

1:00 - 2:00:

2:00 - 3:00:

3:00 - 4:00:

4:00 - 5:00:

5:00 - 6:00:

6:00 - 7:00:

7:00 - 8:00:

8:00 - 9:00:

9:00 - 10:00:

10:00 - 11:00:

11:00 - 12:00:

12:00 - 13:00:

13:00 - 14:00:

14:00 - 15:00:

15:00 - 16:00:

16:00 - 17:00:

17:00 - 18:00:

18:00 - 19:00:

19:00 - 20:00:

20:00 - 21:00:

21:00 - 22:00:

22:00 - 23:00:

23:00 - 24:00:

24:00 - 25:00:

25:00 - 26:00:

26:00 - 27:00:

27:00 - 28:00:

28:00 - 29:00:

29:00 - 30:00:

30:00 - 31:00:

31:00 - 32:00:

32:00 - 33:00:

33:00 - 34:00:

34:00 - 35:00:

35:00 - 36:00:

36:00 - 37:00:

37:00 - 38:00:

38:00 - 39:00:

39:00 - 40:00:

40:00 - 41:00:

41:00 - 42:00:

42:00 - 43:00:

43:00 - 44:00:

44:00 - 45:00:

45:00 - 46:00:

46:00 - 47:00:

47:00 - 48:00:

48:00 - 49:00:

49:00 - 50:00:

50:00 - 51:00:

51:00 - 52:00:

52:00 - 53:00:

53:00 - 54:00:

54:00 - 55:00:

55:00 - 56:00:

56:00 - 57:00:

57:00 - 58:00:

58:00 - 59:00:

59:00 - 60:00:

Description from an attendee at the session

When Tim started talking about about keynote speech, so he kinda had the same topic in mind. With that in mind I want to look at the powerpc chip ca 1995 and if anybody - I will buy them a beer. Quite a while ago. So if you compare this a single-core powerpc with a few devices attached and I thought it was quite and it's not too important to read the text But the important things is to see the template blocks. So, what we're talking about today's SOCs. But this is a fairly typical setup This are on a SOC so we get dual-core A15s as well as a DSP, and then various specialized as well as the normal set of I/O blocks. So what makes these SOCs complex? There is a lot more stuff. We have to fit more things in a smaller space, and we have to fill a lot more processing power in. And the driving factors behind this design of the hardware is that you are squeezing more in. And, another big change from that time from ... is a lot more IP blocks developed by ... so you are taking all these things and squeeze them in. So it's more focused .. on specific areas of technologies that are really important in that area. It's offloaded from the ARM processor. So, as a result, there is a lot of specialized software that needs to go with the specialized hardware. And how we make that specialized software available to generic frameworks, applications, so people actuallY ** use it. If you look at the Apple chip, at the latest Apple chip, the A6, they have three .. many of the other SOCs vendors have quad cores .. today. So what are these complexity variables that are driving the problem here. When we work with OEMs, they don't tell us, yeah,... Another aspect is that it is not even cheaper to do this. As we shrink the .. .. has to incur that cost. That is a pretty big cost .. to incur..

There is more complexity and how they fit together. It takes more time, more people to get that done, but, the hardware guys don't care. And this is part of the ... as a complete solution to the market .. It is our problem to solve to make this complex SOC usable. Not only by the kernel and software developer, but also by application developers and whoever else needs these features. So, as we look at all these things and going back to the block diagram, there is a lot of things here. We only ask ourselves, how did we get the software done in time to deliver to our customers? .. that product timeframe with your desire timeframe to get .. hardware support upstream. You have to take into account .. what pieces are generic and can be leveraged by a number of people? Is it just something specific to TI? .. Or is it generic to how .. we need to use this hardware and expose the .. And then, assuming we can figure that out, can we .. all hardware has a limited timeframe. .. And so, if we can't evolve the kernel fast enough in some of these subsytems - fast enough - the hardware then becomes obsolete in the sense of what's important .. We're operating within that time window when new design .. are important. .. And that's really the sweet spot when the software .. can really invest in doing software correctly and pushing it upstrema. If we cannot fit it into this window .. Finally, who is doing all this work? There is a tremendous amount of work to be done. All those different IP blocks that belongs distinctly to TI. So, the answer to these questions are not easy and we need to figure out what we can do.. -- And also Linaro which is the a newer organization which is focused on ARM SOC manufacturers coming together and solving problems. Another interesting aspect was when TI was working with Google and Android Team for ICS. We had, we called a shared engeering seession .. in SOC. They said, look, we see all the SOCs out there, and this is not going to work out there. .. So now we have something that really very complex piece of software that was internally developed by TI in two much more efficient smaller .. code that has been splitted .. This concept of shared engineering, it's both beyond - it is really more about getting together and understanding detail .. in a way that we co-developed .. sharing the resulting IP. .. .. to solve the problem that all those SOCs are getting more complex .. And so the question they came up, as part of this, so, if we missed that window, does it make sense to upstream at all? .. are doing on the investment on that processor, we re not going to be able to get everything upstream in that timeframe.. Does it make sense to even think about it? But the answer is yes. .. We cannot wait until the chip is done and ready to start our upstream process.

So, like for example, I chose the word "apocalypse". .. It's taking longer to get the software running, it takes a lot more effort, we are running out of time, .. making it to market in time, _and_ figure out in time how to get things upstream.

Linaro had a big part in helping these efforts. Many of the SOC manufacturers and software engineers contributes as well .. So an apocalypse is not always bad. .. And, so again, this is a bit of an example of how we can continue to look at critical pieces of code .. It's easier to add new SOCs into upstream. It becomes easier for silicon companies to .. submit for upstream and propagate that cycle of .. So, what's next? So, there's many things that can come next. What are the things .. you must reduce this complexity. Meaning, we cannot have it so that it takes a long time or..

And there is an example of this .. one silicon company a while back and oh that software at that time and we were trying to figure out how to have a business relation ship. .. and for me to explain so you can develop a software for it. .. But we met with that it would take too much time, that it would not make sense for a .. person to learn the details.. Undocumented ways that the hardware is structured and put together that affects the software .. And that's why you see .. a big surge in the software from the semicon vendors. And the guys now start to .. the only way to do it is to reduce your TCO and get the code upstream. .. So I think mmmmm kinda bringing to a close here, the important for us .. new technology that's been talked about in areas .. Think about what's coming next when .. make sure that the silicon guys are a part of that discussion. Really try to promote - even within your own companies - .. the fact that we need to be working closer together in order to avoid this complexity. .. The only way we can avoid it is to recognize it and .. start focusing on getting this code supported, supported and supported on your SOCs as... as possible.