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

OUTGOING

[Anonymous Coward]

HELLO WORLD
76113 76113
HELLO WORLD
90949 90949 42127 42127 32843 32843 16731 16731 12409 12409
98783 98783 18720 18720 58071 58071 46550 46550 44422 44422
69837 69837 34182 34182 16883 16883 61401 61401 64506 64506
30908 30908 13060 13060 45980 45980 60045 60045 59453 59453
18883 18883 21915 21915 23642 23642 37819 37819 70910 70910
80904 80904 29188 29188 00577 00577 05367 05367 91567 91567
62560 62560 42383 42383 02459 02459 47205 47205 42850 42850
19703 19703 98583 98583 12251 12251 89307 89307 58500 58500
98511 98511 66310 66310 38382 38382 39261 39261 45505 45505
18851 18851 92987 92987 65235 65235 44150 44150 11820 11820
55028 55028 68986 68986 36904 36904 29733 29733 19541 19541
62794 62794 12492 12492 69933 69933 37257 37257 81831 81831
74165 74165 16479 16479 75252 75252 14127 14127 20152 20152
87442 87442 81515 81515 79296 79296 35273 35273 27610 27610
86440 86440 63056 63056 87290 87290 91318 91318 11461 11461
95553 95553 17013 17013 55201 55201 14542 14542 52013 52013
62575 62575 21193 21193 13165 13165 99916 99916 72080 72080
90999 90999 42622 42622 13405 13405 58252 58252 58553 58553
53100 53100 19542 19542 28799 28799 84550 84550 57613 57613
54546 54546 94714 94714 95433 95433 63074 63074 48608 48608
96420 96420 05868 05868 01075 01075 89828 89828 88465 88465
64050 64050 43656 43656 77898 77898 25557 25557 06572 06572
17136 17136 67346 67346 69315 69315 32847 32847 73406 73406
40043 40043 54777 54777 01705 01705 95955 95955 66754 66754
18478 18478 24416 24416 33348 33348 76676 76676 27836 27836
83984 83984 12825 12825 64762 64762 42743 42743 88404 88404
20382 20382 06507 06507 44771 44771 79532 79532 38835 38835
26599 26599 83239 83239 49129 49129 08147 08147 23659 23659
15096 15096 39065 39065 33802 33802 33004 33004 55208 55208
99444 99444 98385 98385 82660 82660 02662 02662 51355 51355
71446 71446 21790 21790 49198 49198 14268 14268 73477 73477
05128 05128 56278 56278 41467 41467 98611 98611 95074 95074
94472 94472 44572 44572 52917 52917 14984 14984 28970 28970
43757 43757 87043 87043 49538 49538 12945 12945 66222 66222
04270 04270 48889 48889 88031 88031 01436 01436 03576 03576
85675 85675 44014 44014 32711 32711 33223 33223 28854 28854
60604 60604 86484 86484 47766 47766 99334 99334 46156 46156
90270 90270 70026 70026 55205 55205 14929 14929 01018 01018
98506 98506 16598 16598 33006 33006 90570 90570 81392 81392
69138 69138 41491 41491 95533 95533 27669 27669 86021 86021
84532 84532 53228 53228 02684 02684 91781 91781 50072 50072
91032 91032 66372 66372 92743 92743 59139 59139 20568 20568
37255 37255 52848 52848 80419 80419 97349 97349 98470 98470
23290 23290 64310 64310 07835 07835 81756 81756 50012 50012
78832 78832 91678 91678 78309 78309 18587 18587 04167 04167
47224 47224 17836 17836 32588 32588 42566 42566 10965 10965
34189 34189 97045 97045 14029 14029 07478 07478 21586 21586
15688 15688 82785 82785 97093 97093 91695 91695 05525 05525
11819 11819 89032 89032 03065 03065 19589 19589 55803 55803
73371 73371 25723 25723 10750 10750 79088 79088 89370 89370
54783 54783 64221 64221 30565 30565 79310 79310 37695 37695
27672 27672 11277 11277 13979 13979 08243 08243 84363 84363
19156 19156 37434 37434 08064 08064 88459 88459 25016 25016
50388 50388 13197 13197 65073 65073 51290 51290 31518 31518
79112 79112 62910 62910 26991 26991 50396 50396 72382 72382
93759 93759 83753 83753 49190 49190 01988 01988 62302 62302
71920 71920 05832 05832 94575 94575 96275 96275 66672 66672
85762 85762 03850 03850 92969 92969 86678 86678 33832 33832
09260 09260 08959 08959 55705 55705 30312 30312 07496 07496
94187 94187 97658 97658 58224 58224 82392 82392 48857 48857
83046 83046 56905 56905 60230 60230 42625 42625 39188 39188
73816 73816 15133 15133 97844 97844 68548 68548 57880 57880
92999 92999 36453 36453 31309 31309 75060 75060 83877 83877
77664 77664 80919 80919 90786 90786 75972 75972 20206 20206
79748 79748 620

Complete series

[Saiyine]

Link to all the articles in order.

Re:Complete series

[AtrN]

At least there's some mention of SoC in the first and second articles. The third article, as linked by the submitter, just says to use revision control and branching. Woop de doo.

This statement, from the second article, worries me,

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. They just looked like one. Sheeeze.... (sarcasm off)

Everytime I read one of these IBM DeveloperWorks links I get annoyed. The articles are either so pithy or trivial I can't see how anyone can find value in them, e.g. this stuff about revision control under the guise of SoC co-design. It's just trivial bullshit. Any half-decent developer type knows this stuff backwards. Maybe this part of IBM is aiming the articles at a different audience? I just don't know.

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.

developers developers developers

[twoes00]

developers, developers, developers, developers.

This gave me an idea.

[Anonymous Coward]

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.

Re:This gave me an idea.

[Anonymous Coward]

Why not just implement a kernel in hardware! I know I'm going to be writting a lot of verilog tonight!

Re:This gave me an idea.

[Anonymous Coward]

If you could write some software that could convert C to Verilog AND recognize what could be done in parallel AND get all the timing to meet, you would be a very wealthy slashdotter. Also, there are no multiple write FPGAs that can exceed a system clock rate of 600 MHz so for many sequential tasks a CPU would be much faster.

Re:This gave me an idea.

[robolemon]

Why assume that a kernel is written in C? I think it would be great if kernel writers could write portions of code in verilog for whatever reason and mix it in with the C.

Re:This gave me an idea.

[JKR]

Check out these guys who're doing just about that. Way cool stuff (disclaimer, used to work there, etc.)

Jon

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.

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)?

Re:This gave me an idea.

[Anonymous Coward]

FPGA's are expensive in terms of materials, production steps, individual testing, die space, electric power, and speed. SoC is all about reducing die space, electric power, & increasing speed and today's market environment is all about reducing time to market by reducing individual testing/failure points, production steps, and cost of materials. For these reasons, FPGAs are some of the last design features a SoC designer looks to.

Re:This gave me an idea.

[doctormetal]

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.

Since when is an FPGA not hardware? You may have variations, like RAM based, ROM based, OTP (one time programmable) or mask ROM (programmed in the factory). It is still hardware.

The clock speed of an FPGA may be lower (nearing 1GHz) than a modern CPU, but they are a lot faster in throughput.
A cpu is general purpose and conatains a lot of 'overhead' you do not need for a dedicated FPGA progrsm.

A CPU must fetch the instruction, decode it, stuff it in the right pipeline for use by the ALU, FPU, bus controoler, etc, and finaly executes it.
On most FPGAs it is much simpler: fetch instruction and execute it.
This makes the FPGAs lower clock speed not an issue.

Most functions don't get 'moved into hardware', but often in mask ROM FPGAs. In larger volumes they are cheaper than normal RAM or ROM based ones.
Only a few companies (the larger chipset makers like intel, via, amd, etc) make a specializedc chip of their design, others use mask ROM FPGAs.

Re:This gave me an idea.

[LWATCDR]

If you want to get nitpicky How can you have a mask Read Only Memory Field Programmable Gate Array?
The discussion was on general purpose CPUs like those used in PCs. The value of adding a FPGA or a CLD to a CPU core to allow new funtions to be added to the CPU.
I was only stating that it is not really worth the cost in a PC like system since any function that gets used enough will eventual get moved into an ASIC which in volume are much faster and cheaper then a FPGA.
Things like MMX, SSE, and 3D graphics chips are prime examples. FPGAs are great in small run embedded systems and I have actually seen a few PowerPC based cpus that had FPGA attached for just that market.
In large volumes ASICs are cheaper and faster than FPGAs. FPGA's are more flexible and ideal for small runs of very specialized devices.

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

Re:nothing new here

[Anonymous Coward]

DEC did this with the VAX and VMS back in the 70's. VMS booted up shortly after the first hardware boot. They even went as far as to determine the most common complex O/S functions and built some of them into the hardware. For example, O/Ses spend a lot of time manipulating queues, so the hardware implemented an Insert Queue and Remove Queue instruction that was atomic and non-interruptable.

Erlang design principals?

[chroot_james]

Can erlang style message passing be built into something that small?

Re:Erlang design principals?

[Mixel]

SoC, so the idea goes, leads to higher density of functionality for the same space/power. Therefore an equivalent SoC system ought to have more room for things like message queues. So, in theory, SoC the size of your typical motherboard ought to handle a lot more messages than your typical motherboard ;)

But, needless to say, there are tradeoffs made in any design.

This is not groundbreaking.

[SpittingAngels]

Ok, so I did RTFA but didn't understand a lot of it because I'm not a developer and ended up skimming through the parts I wasn't following.

But, how is this different from what Apple does with their BootRom?

I understand that in the realm of Windows-based PC architecture this is not common practice but I would not consider is new or groundbreaking and, in fact, it seems fairly obvious.

Someone please post a synopsis for us laymen of what makes this innovative.

Everything old is new again

[dprice]

The concept of software/hardware codesign is not a new one. I would say that every project I have worked on for the past 20 years has been a software/hardware codesign project, regardless of whether it was an SoC or some other hardware system. In every case, I have seen the software start running shortly after the new hardware is powered up. Fast software boot is a validation that you did the design correctly, but it should not be viewed as an amazing feat. It should be an expected outcome that was planned for. Those who design in "silos" are doing it the wrong way from the start and are asking for problems.

Within the last 5 years or so, there has been a lot of hype about System-on-Chip (SoC) development. There have been lots of SoC articles, and many companies trying to sell tools to develop SoC's. But when I read through most of the hype, I find nothing all that revolutionary about the tools and methods. Chip fabrication has reached the point where one can integrate a lot of functionality on a chip, but the design methodologies for successful designs are still basically the same as the past non-integrated designs. Mistakes are less forgiving in an SoC since rework is very difficult or impossible, so the design verification requirements need to be thorough. Most design successes that I have seen have been more dependent on the thoroughness of the design team than the tools used. The best tools in the world will not save you from the blunders of bad designers.

Re:Everything old is new again

[TubeSteak]

Is there any reason hardware design has such a high standard compared to software?

A lot of time, money and effort goes into both processes, but I can't recall the last time I heard about a major hardware flaw.

Is it just easier to debug hardware designs, do they have special automated mechanisms for error-checking...

what gives?

Re:Everything old is new again

[Anonymous Coward]

Not knowing much about hardware design (beyond a 2nd year "digital design" computer science course designed to give us a brief taste of what goes into electrical engineering), I suspect it's because, in (digital) hardware, you can iterate through all possible states to test your whether individual parts satisfy their pre/post-condiitons. It could also be that the entry-level cost to commercial hardware development is high enough to weed out people who don't know what they're doing.

Incidentally, I hope more people like the grandparent post (this is a verb) replies to this story. While the average software development story seems to garner lame know-it-all responses from VB monkeys, I really love the generally more knowledgeable responses on hardware dev stories coming from people who work on hardware for a living (at least in terms of my weak understanding).

Re:Everything old is new again

[Anonymous Coward]

Its mostly due to verification. Chips I've worked on in the past with about 4-5 million transistor equivilents had at least 50 hours of regression tests run every night. There are usually 2-3 verification engineers per designer whose sole task is to write tests that exercise every aspect of the design. Exhaustive cases are usually done where ever computing resources allow.

With $100,000+ on the line if any mistakes are made and no possibly of patches, it's easy to justify the verfication expenses.

Re:Everything old is new again

[dprice]

Is there any reason hardware design has such a high standard compared to software?

Part of the reason is that hardware design by nature is less flexible than software to change, particularly as more hardware goes inside chips. The up front cost of a System-on-Chip can easily be more than 1 million dollars, and the cost of re-spinning a chip to fix a design flaw can be almost as high. And the month or two of time lost waiting for the re-spin also has a time-to-market cost. The high cost justifies the high standard.

I can't recall the last time I heard about a major hardware flaw.

Most hardware bugs are detected in the bring-up phases of a project; and by the time a company commits the money to hardware production, they have a fairly high confidence that the hardware is solid. Most major hardware bugs don't make it to production, so people don't hear about those failures. Hardware bugs that do make it to production go unnoticed, are covered up through software workarounds, or they get a lot of bad press (like the infamous Intel FDIV bug, or more recently the Xbox 360 instability problems).

Companies can afford to put out beta versions and patches of software, so a lot more software bugs are visible outside a company. There is still a cost of having software bugs, particular in critical systems and high volume applications, but fundamentally you can patch software. Patching hardware is possible only if you are lucky enough to have an accessible place to change the hardware behavior, or enough time and money to re-spin. For big complex hardware, designers attempt to put in some programmability to hopefully work around potential bugs, but it takes a lot of foresight to predict where things might go wrong.

With field programmable gate arrays (FPGAs) the hardware does look more like software since you can compile and reload a design into the FPGA chip. I have seen hardware designer be less stringent about FPGA designs because of the increased flexibility. With FPGAs there is a power and cost tradeoff since they are more general purpose. For an equivalent design, an FPGA eats much more power than an equivalent SoC, and FPGAs are typically much more expensive in volume than SoCs. So FPGAs are not a viable solution for things like PDAs, cell phones, and MP3 players where SoC's are prevalent.

Re:Everything old is new again

[scatterbrained]

I agree with the parent 100% - the whole thing boils
down to a few simple ideas:

1) someone has to manage and plan
2) discipline (see #1)
3) adhere to and document defined interfaces
4) get the s/w guys going on a simulator as fast as you can

Re:Everything old is new again

[the chao goes mu]

I can recall one major software bug, the FOOF memory bug on intel processors. Otherwise I would agree.

Re:Everything old is new again

[munch117]

Is there any reason hardware design has such a high standard compared to software?

Any hardware bug that can be worked around in software is instantly reclassified as a software bug.

Seriously.

SOC...

[SpinJaunt]

I dont really want any more SOCks as I have enough to last me till next xmas now, although Linux or NetBSD on SOCks would be cool :)

Why don't we fix software development first.

[Anonymous Coward]

Before corrupting hardware

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.

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.

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.

Not apple; OpenFirmware

[Anonymous Coward]

When you say "Apple Bootrom" I beleive you actually ment:
http://www.openfirmware.org/

Which was originally created by Sun Microsystems, I believe.

IBM released a BSD-licensed version earlier for use in it's PowerPC, POWER, and Cell stuff. Make it more Linux-friendly.

Of course other manufacturers are free to use it in their own hardware. Of course they should keep in open and documented so as to not look like total jackasses and turn something that is supported by many OSes into something that they have to expensively modify and hide from everybody.

Break the Bottleneck

[TheZorch]

Putting the CPU, Chipset, Bios, RAM, and device controllers onto the same chip would erase many of the major bottlenecks effecting today's high-end PCs. Its these bottlenecks, which things like PCI-Express and SATA is trying to eliminate, that keeps today's fast PCs from being as fast as they truely should be.

Transmeta

[hutchike]

If Transmeta proved anything, it was that you get more performance-per-watt and flexibilty by moving hardware into software. I guess that was the point behind the RISC processors that are now delivering up to 32 concurrent threads in hardware. Keeping the hardware simple gives you far greater potential. In light of this, I don't see how "system on a chip" can be a good thing?

Re:Transmeta

[btarval]

I'm not sure if that's exactly what Transmeta proved. But I'll address your last question.

What SOC's do is to simplify the bringup time of new boards. A SOC without a reference port of some software (System Initialization, IRQ handling, device drivers) is almost useless. Without that, the customer has to do the work, which adds time. It's almost always far better to go with a different SOC that has this done, rather than develop it from scratch. Especially if a Linux port is available.

On the hardware side of things, a hardware engineer doesn't have to go through the issue of selecting which Ethernet chip to use (say), and then running the hardware connections to it; nor worry about debugging these connections (including problems here with the manufacturing of the board). Multiply this by the number of devices used on the SOC, and you can see the big timesaver. So much so, that you need a really good reason not to do things this way - because your competition almost certainly will.

So, in short, it simplifies a lot of the development time.

Re:Transmeta

[larry_larry]

What about a custom processor and compiler generator that is optimized to your software algorithm / application? Seems this is what Tensilica is doing.

Sysem-on-Chip (SoC) makes sense when you want high-volume production of electronic systems with specialized hardware / software / programming framework. For example a chip that is a generic platform for a cell phone, with USB, Bluetooth, WiFi, GSM, camera, MPU, DSP, GPS circuitry. Typically the physical and data-link layer processing for this kind of application can not be done in a off-the shelf microprocessor. Putting discreet chips for physical and data-link alongside a discreet microprocessor could be more expensive than a specialized SoC. The more you can put in a single, high-volume chip the greater the economies of scale. A circuit board with fewer chips is cheaper in many senses. Potentially 5 different smart-phone manufactures could use the same chip (or modular chip sub-systems) -- what differentiates them would be the way they program things to offer functionality to the end-customer.

ESL tools

[larry_larry]

As a SoC developer, looking for solutions to help improve dev-team productivity, I'm finding that there is a new breed of tools emerging called Electronic System Level (ESL) tools. These tools help to automate tedious low-level work and facilitate co-development of various aspects of SoC development. When interacting with hardware from a microprocessor, or even for communicating between multiple microprocessors I generally use memory-mapped registers. SpectaReg, a new tool from Productivity Design Tools looks pretty cool. During a recent demo PDTi showed how SpectaReg captures high-level speculations and generates HDL logic, a C hardware abstraction layer API, register-map documentation in HTML and PDF formats, and a self-checking test bench for the logic.

2002, a marketing odyssey

[wild_berry]

Because I'm a minor ARM fanatic, they list the ARM7500 system-chip as a milestone in 1994 and ARM7500FE in 1996. Perhaps not putting the system RAM on the chip excludes it from being a true SoC in IBM's terms. Unless IBM wish us to believe that they invented the universe...