I’ve recently begun to wonder what industry I work in. I had though it was Embedded Systems but recent events suggest that may be incorrect. Some of these events are too overly obvious to be considered meaningful, for example Virtutech has stopped exhibiting at ESC on the grounds that no one attending the show is looking to buy tools for SW development (I will ignore the question of just how many people actually attend ESC). Other events though require more thought. As a recent example Paul McLellan’s recent article “Arm, Atom, PowerPC” on the EDA Graffiti suggested that PowerPC is essentially unused in embedded. Now From my point of view power architecture is more than 75% of what I see, thus I must not be working in embedded, right?
Digging deeper into this brings up the “question of what is embedded?” Reading the comments on Paul’s article it seems that Embedded is defined by number of units with the bar set at the number of units of 32 and 64 bit processors sold by Intel. Or more clearly if you ship more unit than Intel ships Desktop CPUs then you are embedded, if not you are something else. While clear it could suggest that toothpicks are embedded systems.
Now I would define embedded systems as digital systems containing CPUs that do not have a traditional desktop PC/server user interface (screen, kbd, mouse). Unfortunately this definition makes netbooks and some smart phones not embedded, and many might argue that since they contain ARM processors they clearly are. Using this definition I clearly work in the Embedded industry as I primarily work with customers building: Satellites, Airplanes, Military Equipment, Networking Equipment, Telephone Equipment, and Enterprise Compute Servers. (I’ll admit that Enterprise Compute Servers are generally considered traditional computers and not embedded since they are the direct descendant of the first computers but they generally don’t have a keyboard and mouse.) Given that list lets look at the CPUs used:
- Satellites: In the US these are BAE Rad750, a radiation hardened PowerPC750. In Europe they are more likely Sparc. I don’t know about Asia.
- Airplanes: This market is dominated by the Freescale MPC74xx series with a strong showing by the Freescale MPC864x
- Military Equipment: This market is almost exclusively VME or VITA based and most to many of these use MPC74xx or PPC970 based processors though Intel is making inroads.
- Networking Equipment: If we consider the routers and other back end equipment that make the Internet go rathe than the blue box on your desk these are almost all Freescale MPC85xx based. MIPS used to be strong in this market but they stopped making chips. Cavium and Intel are certainly making inroads but the most of current designs and the majority of deployed HW that is being developed for is still MPC.
- Telecom Equipment: All about microTCA, again strongly Power Architecture (all types) but Intel is much stronger here than anywhere else so far. (I am intentionally ignoring the hand set/aka phone, as they are consumer electronics not telecom equipment.)
- Enterprise Compute Servers: if you buy from IBM these are Power, though Sun, HP, and Dell are mostly Intel. Cisco looks to be Intel, but they don’t have much market share yet.
- Gaming Consoles: While I don’t work with these the big three Xbox360, PS3 and Wii are all power architecture.
So given that list I don’t see ARM any where does that mean these aren’t embedded? Perhaps we should look at power instead. I’ll grant that with the exception of Satellites and Game Consoles the system power for these is generally measured in Kilo Watts or Mega Watts not Milli Watts that most ARM based systems are measured in but on a per CPU basis they all care about power consumption. Or perhaps we should consider price, this time none of these systems tend to be < $100 the way most ARM devices are. Perhaps we should look at the SW stack, most of these systems have very large software stacks, roughly divided between general purpose (read linux) and Real Time OS based but in both cases large teams of engineers devote substantial amounts of time to these, unlike many ARM based systems which can still outsource SW development.
What can I conclude from this? That the markets I work in and the markets for ARM based systems are different. Is one Embedded and the other not? Hard for me to say, I’m not in marketing.
Driven by Blogs, ESL
observation
I will be speaking as part of the Power.org panel session on Monday Feb 2 at Design Con 2009 http://www.designcon.com/2009/
ESL, Travel
Conference
<disclaimer>As part of my job I frequently end up translating between two parties nominally speaking the same language with a 50% to 100% overlap in vocabulary where there is only a 0% to 20% overlap in the meaning of the share vocabulary. </disclaimer>
I am frequently surprised at how many people don’t place any value in defining key vocabulary before beginning a discussion. In particular I have recently been involved in several industry consortia where there was a debase as to the merit of defining key terms at the beginning of a document being developed as a standard. I find this debate particularly annoying as it was clear during the conference call the different member of the committee were using the same words to mean vastly different things. I would have though the rat hole the discussion dived into as to the meaning of terms would have settled the question of defining the terms in the document but no such luck. Ah well, the wonders of committee work. (I did get the section of vocabulary included in the document it just too more work than it should have.)
My current pet peeve of shared vocabulary with inconsistent meaning:
Define the following terms: thread, task, process, job, strand, program, and context
Now pretend you are a SW designer instead of a HW designer, or vice-versa, and redefine. How many terms had the same definition?
ESL
almost rant, Vocabulary
For better or worse I’ve started to become familiar with the OSCI TLM 2.0 standard, and have to ask the question “why has OSCI specified a protocol with out formally defining the state machine that implement the protocol?” I suspect the answer is because no one has formally defined the state machines or state transitions.
I’m motivated to ask this question because back in 1999ish at the University of Wisconsin we came to and published the conclusion that you can’t formally reason about the correctness of a cache coherence protocol with out formally defining the state machine that implement the protocol. To further this work a language for specifying state machine in the context of coherence protocols was developed that could generate documentation, PDF, HTML, and executable simulation code. I believe the first publication of this methodology was in:
Specifying and Verifying a Broadcast and a Multicast Snooping Cache Coherence Protocol, Daniel J. Sorin, Manoj Plakal, Anne E. Condon, Mark D. Hill, Milo M. K. Martin and David A. Wood,
IEEE Transactions on Parallel and Distributed Systems, June 2002 (vol 13, number 6).
(Previously available as Dept. of Computer Sciences Technical Report CS-TR-2000-1412, March 2000.)
So given a methodology for clearly specifying complex protocols published in 2000 why isn’t OSCI using it (or something better) in 2008?
ESL
Academic Publications, Wisconsin GEMS, Wisconsin Multifacet
In reading several blogs and newsletters recently I’ve gotten annoyed that people don’t say what they mean. There is talk about how to design better interfaces and how to document them better but this misses the point that without the interface any possible functionality doesn’t exist. Further the authors never get around to simply stating
Design the Interface First.
To unravel this though:
Jakob recently introduced me to Gary’s newsletter. So I started reading the back issues. Two in particular The (not so) Exciting World of Documentation and Accurate Register Specifications caught my attention. In the first Gary talks about the trouble generating accurate documentation for hardware designs and suggest that hardware engineers have firmware engineers review the documentation to ensure that it is comprehensible. He also discusses the difficulty in documenting the interface after the fact. In the second Gary suggests using a register design tool. Jakob then comments on this in his blog stating
“You really need a full expressive language to write a truly executable model of the hardware.”
Now all of this is well and good, and I happen to agree, but why do they go on at such length about their topics instead of just getting to the my point:
Design, document, and declare the interface first, then worry about implementing any functionality that may be triggered by calls to/interactions with that interface. Without the interface the functionality doesn’t exist.
I feel particular passion about this topic because of a situation I’ve run into with a customer with where over a year ago we were told (paraphrased)
We can’t give you the documentation on the interface to, or basic functionality of, our part in time for you to complete a high level functional model 6 months from now; we haven’t designed the interface and the documentation hasn’t been started. However we have the detailed model almost done we can integrate our detailed model with the functional framework in plenty of time.
I didn’t believe this at the time, and the detailed model ended up being about 3 months late before the integration really started working. The interface to the functionality is still being updated and the documentation still isn’t complete. Further as the firmware and unit tests gets written it becomes increasingly clear that the interface was never “designed” as such, rather it was just slapped together with the hope that it was good enough. Cases are still being found where functionality can’t be tested because there is no interface to it.
From this I draw the conclusion: functionality doesn’t exist until it has been tested through a well designed external interface, simply writing the RTL isn’t enough.
[edit]
Jakob points out that he did present this sentiment but not quite as clearly as I would have liked.
Driven by Blogs, ESL
rant