System on a Chip Concurrent Development

An anonymous reader writes "The old silo method of chip development, with hardware and firmware developers barely interacting with each other, won't cut it in today's fast-moving industry. IBM DeveloperWorks has the third in a series of articles about system-on-a-chip design. The author, Sam Siewert, displays the development tools and processes that speed system on a chip design and get all your developers working together effectively."

Comments

Complete series

[Saiyine]

Link to all the articles in order.

Re:Complete series

[dprice]

"The SoC emerged as a design concept as early as 2002."
Guess that stuff we've been doing for over a decade ago wasn't SoC work then.

You're right, that statement is uninformed fluff. Back in 1999, I remember going to a design conference, and SoC was THE big topic of the conference. SoC as a term predated that conference by a number of years. In many ways SoC is a lot like the term AJAX. It is a combination of technologies that are already in use, but now there is a marketing buzzword to identify that combination.

I think these IBM articles are driven from the marketing department for promotion. Even when the author is some academic person, they probably have some ties into a marketing department to give some technical merit to the marketing hype. Unfortunately, there isn't much depth to those articles.

nothing new here

[wannasleep]

Hardware-software codesign is nothing new and revolutionary. It has been taught for years at berkeley and around the country. A bunch of links can also be found here

Yes and no.

[btarval]

I can't speak for what's taught in the Universities nowadays, but I can tell you that the decreased development time in industry is relatively new. So much so, that I've seen a number of companies fall down when trying to figure out what to do. I've also seen a number of successes when they get things right. But people who understand the entire modern cycle (theory AND practice) seem to be the exception, and not the norm.

So it's nice having these kinds of articles around, as they tend to reinforce the obvious about current practices. You'd be surprised how many companies don't understand these things.

Two of the most important things (on TFA's list of recommendations) are, IMO:

"1. Identify hardware and firmware module owners to take responsibility through entire life cycle."

"2. Adopt configuration management version control (CMVC) tools that allow for feature addition branches and version tagging."

The other items are important. But these two stand out, as their impact has ramifications in the other areas.

For #1, this can be characterized as "Avoid the Netscape Development Model". That is, there is no single owner, and everyone gets to make whatever mods they want. This leads to excessive code bloat, broken API's, and no one single person responsible for fixing a specific section. It's typically brought about by total mis-management of the project, by MBAs. It's truly amazing that the majority of managers out there simply don't understand this.

And sorry to pick on Netscape, but the stories involved with their engineering mismanagement here are rather noteworthy.

For #2, the right SCM selection is critical; and the wrong one ends up costing not only money, but even worse, time. While branching and tagging is important (does any modern SCM not have this?), there are a lot of subtle issues which you can't see based upon the marketing blurbs.

A superb example of the hidden costs is ClearCase. Regardless of whether you love CC or hate it, it ALWAYS soaks up a lot of resources. Aside from the servers required (assuming they don't go down at critical times), I have yet to see a ClearCase project which didn't have an absymally low ratio of developers to SCM engineers.

Modern SCM systems (like bitkeeper) should have one SCM engineer per hundreds of developers (at least). With ClearCase, it seems like the ratio is in the tens (or perhaps a hundred if you're lucky).

Finally, what IS somewhat new (and not mentioned really in the article), is the incredible speed in development by using Open Source. There is no faster development model with the Closed Source approaches, because you ALWAYS run into things that you didn't foresee; and you either cannot solve them with Closed Source, or it will end up costing you significant money (and additional time) to surmount the issue.

But with Open Source code, you can either solve the problem immmediately; or, someone else has come across the problem, and has a solution already in place.

I pity (and avoid) the companies which don't understand all of the above points. I also prefer to work with their competitors, as I like having successes on my Resume, and not also-rans.

Re:This gave me an idea.

[LWATCDR]

FPGAs tend to have a much lower clock speed than most CPUs. What tends to happen in mainstream hardware is first a function is done completely in software. As more and more users use those functions they get moved into hardware. FPGAs are sort of a halfway step. Functions that are not fast enough in software but not used by enough people to put into hardware.

Re:This gave me an idea.

[bheading]

Software to run C code on an FPGA already exists. Here's a book on the subject.

I leafed through this book in a bookstore a while ago. The type of thing they do at the moment is mostly DSP/heavily algorithmic stuff, ie like encryption, compression or checksumming etc.

An OS kernel is mostly shifting data structures around; the algorithms are very clever but also computationally relatively lightweight. In terms of choosing the best way to allocate real estate on a CPU die, an FPGA would not provide the same benefit as much as a CPU hardwired to help the OS as much as possible (eg context switching hardware, high speed caching, multimedia SIMD instructions etc).

The main problem with FPGAs at the moment is that they are expensive relative to hardwired devices. Their main use is still prototyping or research. Once you've designed a really useful device with one and made it stable, you'll want to turn it into a hardwired ASIC if you're producing the hardware in any kind of volume.

It's been done

[seanadams.com]

Why not make a CPU with a built-in FPGA, then load bits of the kernel into that hardware?

Call me crazy, but that might be more efficient than just throwing more cores at the problem.

Here's one: Atmels' 20 MIPS processor + FPGA

The problem is, fast processors are now SO cheap that the applications for a part like this are incredibly limited - you end up with the wrong FPGA and the wrong uP for more than it would probably cost you to buy the right architecture as discrete chips.

Re:This gave me an idea.

[Jerry Coffin]

Why not make a CPU with a built-in FPGA, then load bits of the kernel into that hardware?

Were you thinking of something a lot different from the Xilinx Virtex 4 FX, Altera Excalibur or Atmel part (referred to elsethread)?

FPGA + Embedded C + PCB

[Anonymous Coward]

http://www.altium.com/

    Check out Altium Designer, FPGA + Embedded C + PCB design all under the one hood, with all the handy things that come from having them all under the one hood.