Archive for October, 2008

Embedded Systems Conference

Sunday, October 26th, 2008

I’m right now attending the Embedded Systems Conference in Boston. I’ll use this post to add my reflections on what’s being presented and discussed here as well as the trends that I can identify from e.g. the exhibition part of the conference.

So, stay tuned, I’ll keep this post updated over the week.

First day: Architectural Design of Software for Multi-core Systems, by David Kalinsky.

All in all, it was an OK show (I went there to see if any new stuff popped up), but it was targeted mostly to newcomers and he chose to omit some key stuff (like frequency-heterogeneous chips, i.e., chips where cores have same ISA, but run at different frequencies or transactional memory). However, he insisted on one issue that I’m happy to see spelled out so clearly – the fact that SMP OSes are bound to reach their maximum potential soon and new approaches will be required for chips with tens or hundreds of cores. He advocated AMP with small local cores, which definetly is a possible approach (I’ll come back to this subject in a later post, as promised earlier).

Second day
I went to a set of talks on virtualization. The overall trend seems to be that RTOS vendors are morphing themselves into VMM providers, following on an argument that if you need real-time performance, you need to allow direct access to HW through RTOS – then the logical next step is to add other guest OS-es on top of the RTOS. I must say, it seems like a reasonable argument and quite compelling.
An interesting thing I learned is that NSA is not certifying as safety critical any design based on multi-core chips, because they don’t know how to do it! Amazing, I must say…

Third day
In the morning, there was a keynote talk by Martin Cooper, considered the father of mobile phone. Well, I can’t agree with some of his statements (mobile broadband is not happening, operators will not give up their ‘walled garden’ approach etc), it felt like this talk should have been given two years ago.
Microsoft put up the strongest show with their Windows Embedded offering. Basically they have re-branded everything ’embedded’, up from CE to Vista-based customizations. Obviously they are out to get traction and are announcing a contest for designing the coolest application with a 15KUSD prize.
Other stuff during the day included several talks on Agile methodology. Gee, I couldn’t believe my eyes when one of the presenters talked for 1,5 hours on the type of documentation, process material and other stuff that one should produce – in his opinion – to be ‘agile’. It just sounded strange to talk about ‘agile’ in that context …

Day four: the IBM surprise
Well, this was the ‘bomb’ of the week – at least from my perspective. IBM’s Scott Ambler (their Agile Practice Leader) and Terry Quatrani (IBM’s UML evangelist, formerly with Rational, acquired by IBM) more-or-less said that modelling is just for the sake of communication, since very few people actually use it for e.g. code generation. Oh my, it sounds strange when coming from a tool vendor who acquired Rational, Telelogic, both promising on delivering good modelling tools and code generation support. When I asked Terry how would she still sell modelling tools to companies, she replied that, of course, if you succeeded with it, modelling and code generation are still helpful. That was reassuring, thanks Terry.

Last day
I was hesitating between several whole-day tutorials but finally went to Jack Ganssle’s talk on managing embedded projects. Well, that was quite educative and eye opening, not so much through some magic solutions he would have offered, but through the research data that he has shown, shedding a new light on some issues. Here are a few of these:

  • Of the 9 billion CPUs sold in 2005, two thirds were still 4&8 bit
  • According to the survey of 35000 programming projects, 64% of those with over 10MUSD budget were “challenged”, the rest failed
  • If you modify 50% or more of re-used code, your savings tend to be negligable
  • This was perhaps the most interesting: in a small project, the ‘best’ programmer produces 6x more code than the ‘worst’ one; in a project with 64 members, the ratio falls to less than 2x, for 1000+ sized projects, it’s basically negligable
  • properly done code review seems to be 4x more effective (in terms of time needed to find a fault) than any other testing method

Well, thanks Jack, this was really a nice show … and that was a nice way to end a 5 day long conference.

Etimológia á la Üni

Tuesday, October 14th, 2008

Az elmúlt idöben Üni egyre határozottabban juttatja a világ tudomására a véleményét, immár ‘szavak’ segítségével is. Az egész kb. 2 hónapos korában kezdödött, amikor is a pelenkázóján fekve tartott elöadást a falra ragasztott majmoknak, valahogy ilyen formán: ‘eee-ee-eeeee-hööö-eee-eee-e-hööö!’.  Egy idö után  a két majom vette a lapot – legalábbis így gondoljuk, lévén, hogy Üni egyszer csak abbahagyta a szavalást és figyelembe se vette a majmokat.

Cserébe egy idö után felénk irányította figyelmét. Az elsö figyelmeztetés így hangzott: ‘nem-nem-NEM!’ (valahogy olyan hangsúllyal mint mikor mi, felnöttek azt mondjuk, hogy ‘nem, nem és nem!’). Vicces volt mikor egy-egy kérdésre, nyilván véletlenül, rávágta határozottan, hogy ‘NEM’. Például:

Andi: ‘Manóka, holnap megyünk Verushoz’ (a neuvolás tanácsadónk)
Üni: ‘Nem! Nem! Nem!’

Ezt további ‘szavak’ követték: ‘ma-ma-ma’, ‘ba-ba-ba’. ‘da-da-da’, söt, ‘va-va-vau-va’, különbözö hangsúllyal és hangerövel – és itt kapcsolódik a téma az etimológiával.

Szerény amatör véleményem szerint nem véletlen, hogy a kisgyerek magyarul ‘baba’, finnül ‘vauva’; az anyuka sok indo-európai nyelvben ‘mama’, söt kínaiul ‘ma’ – ezek biza mind-mind hangutánzó szavak és Üni elödjeinek (önmagunk totyogós verzióját is ideértve) a termése. Másképp mi magyarázná meg az ‘anya’ szó hasonlóságát a kínai és indo-európai nyelvek között?!

Érdeklödve lesem, milyen további etimológiai felfedezésre vezet majd rá Üni – ki tudja honnan származhat a tata/dad/father/apa szócsoport is 😉

Tikk-takk, hol az óra?

Sunday, October 12th, 2008

Tény, hogy Üni – mint miden gyermek, gondolom – lelkesen érdeklödik a müszaki tárgyak iránt, úgy mint kábelek, távirányítók, telefonok – és órák. Ezek között is a nagy kedvenc a konyhában fityegö Ikeás óra.

Ez amolyan egyszerü, kerek fa lapon fekete számok és két mutató típus, öreg szolga, az egyik elsö finnországi beruházásunk. Mindig megcsodálta mikor elmentünk elötte,  vigyorgott is lelkesen – ez adta az ötletet, hogy megpróbáljuk rávenni, mutassa is meg, hogy hol a tikk-takk. Örömmel tudatom, hogy pár napja összejött, Üni lelkesen mutogatta, Andi kérésére, hogy ott van ám a tikk-takk a tükör felett, a konyhában. Próbáltuk arra is rávenni, hogy megmutassa édesapát, de erre már csak kinevetett – igaza is van, elég nagy darab, hogy látható legyen, föleg, ha elötte áll 😉 . Így vagy úgy, elörelépés és most már lelkesen dolgozunk a ‘hol a panda?’, ‘hol a maci?’ témákon is.

De hát azok nem müszaki tárgyak, kit is érdekelnek igazán?!

What’s a programmable core and the web-server test of genericity

Sunday, October 12th, 2008

I’ve received a comment to one of my previous posts asking about what lifts a piece of HW out of the obscurity of HW accelarator and makes it a programmable core? Is a piece HW acting based on a regexp script programmable or not?

Interesting question, indeed. It underlines one of the trends I’ve mentioned in the same post, i.e., the shift from hard-coded HW to software-configured HW. But really, where do HW accelerators stop and where do programmable cores begin?

I believe one of the differences lies in (configurable or not) pre-defined logic (what and how hard-coded) and definable logic.  If what the HW is capable of doing is pre-defined, specific and no other things can be done by that HW and the only thing a programmer can do is perhaps to send a static set of configuration data to it- then that HW is a non-programmable, potentially configurable accelerator (or device). My alarm watch falls in this category; an Ethernet MAC and most of IP accelerators fall in this category.

On the other hand, if the programmer – or the user – has to put some creative effort into getting the HW working, then that piece of HW is a programmable core. An FPGA is in my view a programmable HW core (though many HW designers would debate this…) and so are obviously all processor cores with a set of instructions that allow the programmer to define what it shall do and how. The key point here is that the programmer has to define the what and to a very large extent the how for the HW.

So are regexp driven hardware solutions programmable cores? Is a piece of silicon performing deep packet inspection based on a set of rules it receives programmable or not? Obviously, the programmer defines to a very large extent the what component – but the how part is largely left to the HW. I sense a similarity here with functional programming where no order of execution is set explicitly, still we define the how of the calculations to be performed. Perhaps the same is true for the regexp-driven HW: we still define the how – but on a higher level; we define the how for computing whether a packet fulfills some rules or not. That makes these HW programmable core – just the specialization and purpose is different; hence these are programmable, special purpose cores; the ISA is defined by the regexp constructs.

Finally an addition for the generic vs specialized core debate.

I remember a DSP vendor arguing that their DSPs are general purpose and using one argument to underpin that statement: it’s possible to run a Web-server (albeit with limited capacity, obviously) on their DSP; they even referred to some paper (the title of which I didn’t write down, unfortunately) arguing that what makes a processor generic is its capability to run a Web server written in plain C.  Interesting thought – I find it difficult to argue with it with hard facts, though it somehow feels just ‘not quite right’

But maybe it’s just me being too specialized.

The problem is many-core…

Thursday, October 9th, 2008

My employer recently published a short article on the challenge of multi-core and many-core processors on our industry. In short, our position is that just a few cores are not a real problem, but beyond 16/32 cores, the issue of OS, schedulability, reliability will be an issue.

What really is surprising is the limited research – at least in the public domain – around operating systems for many-core processors, especially ones with space-shared semantics. Are we just blind at this problem? Don’t we see that SMP doesn’t really fit these processors?

In one of the next posts I’ll elaborate a bit more around this issue…