MIPS, Mario, TV, and Trends
(Jim Turley)
What Do We Do About Multicore?
(Jim Turley)
Obscurity and the Illusion of Security
by Gernot Heiser, Open Kernel Labs
Engineering or Craft
Developing Safety Critical Software and Systems
(Dick Selwood)
What the Hell Were They Thinking?!
(Jim Turley)
Atmel SAM3U Boasts Screaming USB
(Jim Turley)
Dhrystone Is Dead; Long Live CoreMark!
(Jim Turley)
Powering Up
Mocana Lights up a Freescale Encryption Accelerator
(Bryon Moyer)
[archives]
|
NEW! CHALK TALK
 Power Estimation in a High-Level DSP Design Flow. Want your DSP design to consume less power? Join Amelia Dalton as she talks with Tim Vanevenhoven of Xilinx about new methods for estimating and reducing power consumption in FPGA-based DSP designs. (Xilinx)
CHALK TALK
 Improving Software Development Productivity With Virtual Platforms. Are your SoC and embedded design projects increasingly dominated by software development schedules? Join Amelia Dalton as she talks with Frank Schirrmeister of Synopsys about ways to improve software development productivity using virtual platforms. (Synopsys)
CHALK TALK
 From Desktop to Target: What you need out of Your Development Suite.
Is embedded software development and debug a challenge for your team? Join Amelia Dalton as she chats with Jit Sivalogan of Mentor Graphics about setting up a productive environment for embedded development. (Mentor Graphics)
|
CHALK TALK  Simplified Verification of DSP Algorithms in Hardware. Moving algorithms from MATLAB to FPGAs? Join Amelia Dalton as she explores options for verifying DSP designs implemented in FPGAs with Tim Vanevenhoven from Xilinx. (Xilinx)
CHALK TALK  Using Embedded Hypervisors in Mobile Devices. Join Amelia Dalton as she explores the use of embedded hypervisors to create safe and secure software for mobile devices with Rob McCammon of Open Kernel Labs. (Open Kernel Labs)
CHALK TALK  Embedded Networking With MicroBlaze and Spartan-3A FPGAs. Join Amelia Dalton as she works her way to "Hello World" on an FPGA-based embedded system with Xilinx Spartan-3A and MicroBlaze. (Xilinx)
[previous webcasts]
|
|
MIPS, Mario, TV, and Trends
(Jim Turley)
This week, MIPS Technologies announced that it’s scored another TV set-top box design win. Specifically, the company proudly bragged that NXP (formerly Philips Semiconductors) is using the MIPS 24K processor core in its PNX85500 HDTV chip. It’s the first TV chip to be fabricated in 45-nm technology, a significant if short-lived distinction.
With all appropriate kudos to MIPS and NXP, the more interesting story here is why NXP chose to use a MIPS processor. The short answer is, because they had used MIPS before. In a word, inertia.
Inertia is a powerful force, both in physics and in embedded-systems engineering. “Don’t fix it if it ain’t broke” is a common expression around many engineering labs (or it should be). Engineering is all about building on what you’ve created before. Reinventing the wheel is frowned upon; extending upon proven and stable platforms is the way forward.
That means we often find ourselves saddled with yesterday’s decisions. A previous engineer’s choice of component or compiler can limit our choices today. Legacy decisions can stick around for an awfully long time. And no decision is stickier than the choice of microprocessor. [more]
|
What Do We Do About Multicore?
(Jim Turley)
I’m always suspicious when a PowerPoint slide says we’re at a turning point in history. It strikes me as egotistical to think that today is somehow qualitatively different from yesterday. Sure, chips always get faster and software always gets more complex – how is that an inflection point? You’re just trying to sell me something, aren’t you?
The exception to this self-imposed rule is multicore microprocessors. I really do think that multicore is a game-changer. It makes hardware design different, it makes software design different, it makes EDA and software-development tools different, and it makes jobs different. Multicore isn’t just “more better faster.” It’s time to think different.
Paradoxically, multicore has been around for a long time. Talk to anyone in research or university, and they’ll tell you they have been studying, modeling, and even building multicore systems for decades. It’s only recently, however, that the multicore phenomenon has entered the public consciousness. Everyone thinks it’s new when in fact it’s been around for ages. That’s both good news and bad news. [more] |
|
Obscurity and the Illusion of Security
by Gernot Heiser, Open Kernel Labs
Eric Raymond, prominent voice in the open-source movement and author of The Cathedral and the Bazaar, stated it well: “Any security software design that doesn’t assume the enemy possesses the source code is already untrustworthy.” Decades earlier, Claude Shannon was even more succinct: “The enemy knows the system.” Security experts call this Kerckhoffs’ Principle, in honor of a 19th century mathematician who first formulated it for cryptosystems. The underlying assumption is that any security-critical flaw will be found and exploited sooner or later, so at best, secrecy buys you only some delay.
Despite all this, there’s a widespread yet mistaken belief that security of a system requires that the code is secret or obfuscated, an approach summarized as “security by obscurity.” Here are a few recent examples. [more]
|
Engineering or Craft
Developing Safety Critical Software and Systems (Dick Selwood)
This article has been in production for some time. It was going to be so simple: chat to two of the leading pundits on system safety and pull together a quick piece of “compare and contrast.” Just to add to the timeliness, there has been a very genteel firefight over the role of the IEC 61508 standard on the leading system safety newsgroup (http://www.cs.york.ac.uk/hise/sc_list.php), and, sadly, Air France flight 447 has disappeared, leading to intense speculation as to whether the cause was related to the fly-by-wire systems that the Airbus 330’s (and other Airbus models) use extensively.
However, the conversation with the experts and the subsequent reading had me reaching for my “I think you will find it’s a bit more complicated than that” t-shirt. In fact, in the words of the old joke, “If you want to get to there, I wouldn’t start from here.” [more]
|
What the Hell Were They Thinking?!
(Jim Turley)
Some things were just made to go together (peanut butter and jelly) and some just weren’t, (those two teenagers in the Classmates.com pop-up ads). Now the embedded industry has a new mashup: Intel and Wind River Systems. The #1 chipmaker has hooked up with the #1 embedded-software company. Is this a match made in heaven or a disaster waiting to happen?
So far, I like the deal. It draws public attention to the oft-neglected embedded market, it gives Linux a boost (possibly at the expense of Microsoft), and it underscores Intel’s commitment to embedded systems. As long as PC sales were booming, Intel and AMD had an on-again, off-again relationship with embedded designers. Sometimes they liked us and sometimes they ignored us. Now that Intel has put down serious money on embedded software, we can safely assume the company is now with us for the long haul. [more]
|
Atmel SAM3U Boasts Screaming USB
(Jim Turley)
Atmel made its name with programmable logic and nonvolatile memory, but the company is now a big supplier of microcontrollers, too. It’s one of the earliest and oldest ARM licensees, and this week the company announced an interesting new ARM-based processor chip that might move Atmel to the front of your shopping list.
The new SAM3U chip (full name: AT91SAM3U) slots in between the company’s existing ARM7-based processors (SAM7) at the low end and its ARM9-based chips (SAM9) at the higher end. Atmel’s ARM7 chips have been very popular, but the old ARM7 processor core is starting to look a bit tired; new customers are more likely to be eyeing the Cortex-based SAM3 chips. Atmel’s not ready to pull the plug on ARM7 yet, however. The company plans some process shrinks that’ll push the older chips’ performance upward and keep the hundreds of existing customers happy and well-supplied. [more] |
Dhrystone Is Dead; Long Live CoreMark!
(Jim Turley)
“There are lies, damn lies, and benchmarks.” With apologies to Mark Twain (or possibly Benjamin Disraeli or maybe Henry Du Pré Labouchère), benchmarks have been used and abused ever since there have been computers. Like the question about when the first auto race was held (“as soon as the second automobile was built”), the question of who makes the fastest computer has beguiled and bedeviled engineers for ages. Now, just maybe, we may be making progress toward settling that dispute.
The bigger the computer, the bigger the benchmark. Conversely, testing just the microprocessor by itself requires only the simplest of code loops – or so it might appear. But even the simplest benchmark distorts the true nature of the processor you’re testing, as any “marketing engineer” can tell you. No matter what you measure – clock speed, arithmetic agility, procedural proficiency, or what have you – you’re always leaving something out. No synthetic test can truly encapsulate all the goodness (and badness) of a microprocessor. [more] |
Powering Up
Mocana Lights up a Freescale Encryption Accelerator
(Bryon Moyer)
They were completely unprepared for what they saw when they stumbled upon it. This was supposed to be wild, untouched back-country. As far as anyone knew, no one lived this far out in the woods. And yet there it was: an old cabin, dilapidated but for the primitive upkeep that kept it intact.
There was only one inhabitant; no one knew who he was. From what they could guess, his parents had died when he was a kid. At the time, he must have been old enough to have learned to talk and scratch out an existence but not old enough to have been exposed to the outside world, an activity likely undertaken rarely by his parents. They affectionately referred to him as Wild Thing. [more] |
[previous feature articles]
|
