Slashdot Mirror

← Back to Stories (view on slashdot.org)

System on a Chip Concurrent Development

Posted by ryuzaki0 on from the plug-and-work dept.

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."

3 of 41 comments (clear)

  1. Everything old is new again by dprice · · Score: 4, Interesting

    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.

  2. Re:This gave me an idea. by JKR · · Score: 3, Interesting

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

    Jon

  3. Re:This gave me an idea. by doctormetal · · Score: 2, Interesting
    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.