Are you in tune with the bare naked realities of MPSoC development? System Realization in the 21st century.

My good friend Jack Ganssle just published a terrific article for www.embedded.com titled “Mars ate my spacecraft!” Ganssle is the most accessible authority on firmware development that I know and his article (a fast and easy read) is must reading for anyone involved with System Realization. From the title, you might guess that this article is about the Mars Climate Orbiter, a spacecraft lost in 2001 because of a communications problem between NASA and the private engineering team that developed the hardware to NASA specs. NASA used the metric system. The development team didn’t. The mismatch ended up embedded in the spacecraft’s navigation firmware. As a result, the spacecraft entered the Mars atmosphere low, failed to brake properly, and likely shot out past Mars.

Mars has a well-earned reputation as a spacecraft killer.

However, Ganssle’s article isn’t about the Mars Climate Orbiter. It’s about several other systems that ended in or experienced disaster, generally because of software and always because of inadequate testing. There’s the Mars Polar Orbiter that embedded itself in Mars, the pacemaker that drove weak hearts to 190 beats/sec, the Therac 25 that surreptitiously cooked cancer patients with an overdose of X-rays if the radiology technician hit the wrong key sequence, the Titan IVb launch vehicle that misplaced a military communications satellite, and the Mars Expedition Rovers that were almost lost due to data-file storage exceptions, to name a few of Ganssle’s examples.

Why is there never enough time for adequate testing, especially for complex systems? Because we have a global engineering culture steeped in late system integration. One of the biggest issues along these lines is late hardware/software integration and the problem isn’t going to get better because of the migration to multicore processor and MPSoC design. It’s going to get worse—if we don’t do something.

These issues are at the very heart of System Realization. Look at the ITRS roadmap and you’ll see that it software-development costs equal hardware-development costs for the typical project. (Just check out http://www.itrs.net/reports.html or any EDA company’s latest CEO keynote for a copy of the relevant chart.) Yet we still seem to treat software development as an afterthought, as evidenced by the disasters chronicled in Ganssle’s article.

Ganssle writes: “It’s true that the software embedded into these marvels has grown steadily more complex over the years. But that’s not an excuse for a greater recall rate. We must build better firmware when the code base grows. As the software content of the world increases a constant bug rate will lead to the collapse of civilization. We do know how to build better code. We chose not to. And that blows my mind.”

System Realization adheres to the belief that software development and hardware/software integration must start as early as possible. When is that? At the very beginning of the project. Not some time later. Not after the hardware’s taped out. Not after the chip has come back from the fab. Not after the chip has been soldered to a prototype board.

At the very beginning of the project.

Normally, these haven’t been issues addressed by EDA companies. System Realization, one of the three EDA360 tenets, says that EDA companies must address these issues. That EDA companies are actually in the best position to address these issues.

That is why Cadence introduced the System Development Suite yesterday—to help development teams start to develop real, testable code at the very beginning of a project. This is EDA that has now become mandatory because embedded software is now mandatory; you don’t develop MPSoCs without thinking about, without developing, and certainly without testing software.

Cadence Virtual System Platform

The Cadence Virtual System Platform, part of the company's System Development Suite, permits early hardware/software codevelopment. This image shows Google Maps running on a virtual mobile handset developed with the Virtual System Platform.



According to Ganssle, NASA’s credo here is “Test what you fly. Fly what you test.

Successful system and semiconductor vendors are going to adhere to that credo because they don’t want to become examples in Ganssle’s next article full of ghastly design fiascoes. What do you want to bet that they’ll be relying heavily on System Realization tools to do that?

About sleibson2

EDA360 Evangelist and Marketing Director at Cadence Design Systems (blog at https://eda360insider.wordpress.com/)
This entry was posted in EDA360, Firmware, System Realization and tagged . Bookmark the permalink.

One Response to Are you in tune with the bare naked realities of MPSoC development? System Realization in the 21st century.

  1. Pawan Kumar Fangaria says:

    Very true. And that is where testing the whole SoC in Virtual Platform environment – H/W and S/W embedded becomes compelling. In my view the testing part should be done by an independent entity who can be provided with just the information about interfaces with IP blocks. TLM 2.0 standard can help here in standardizing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s