For decades systems designers and IC designers have taken different paths. The former have relied primarily on block-level schematics for hardware definition. Except for teams facile in FPGAs, they have treated the chips in their designs as frozen blocks. For verification they have trusted prototypes over any form of simulation.
In contrast, IC designers long ago moved to language-based hardware description—first to describe the flow of data through registers in a synchronous digital design, and later to describe the function and interconnection of blocks at behavioral level. These designers, constrained by the multi-million-dollar costs of building a prototype IC to see how it works, rely on software simulation and formal analysis as verification tools, selectively using FPGA-based prototypes to complement these approaches.
The two groups appear to have little in common. But an interesting set of forces is bringing them into closer proximity.
It is getting harder to prototype at the systems level. The rapid growth in IC pin counts, I/O frequencies, and edge rates mean prototype boards are hard to design, often require iterations, cost a lot, and are hard or impossible to patch. A project trying to exploit the latest silicon may not have access to the ICs early enough for the software development team to stay on schedule. System test in prototypes may require hardware—a 300-ton mining machine, say, or a speeding Prius—that you would prefer not to attach to an early-stage prototype. For such reasons systems design teams are beginning to use simulation more widely.
At the same time, IC design flows are developing more of a systems flavor. After heroic efforts to manage energy consumption at the circuit level, chip architects are shifting their attention to systems-level power analysis. Verification engineers are looking for system-level constraints—“Oh, we never actually enter that mode …”—that can simplify their challenges. Design of high-speed I/Os must extend from the logic through the I/O pads, the package, and onto the board on which the chip will be used. And just as in systems design, many IC projects are coming to be dominated by their accompanying software development effort.
Yet systems designers and chip designers remain profoundly different, separated by education, vocabulary, and outlook. I don’t expect the two groups to merge. But I do expect, as the challenges of chip and systems design grow more similar, an osmotic exchange of tools and methodologies across the boundary that divides them.