It is a sure bet that the buzzword at the upcoming Design Automation Conference will be: Multicore. Computational complexity in many EDA applications has grown to the point that it is no longer efficient to depend on a single stream application for results. Since we are learning to develop solution for more complex problems in other areas beside EDA, semiconductor vendors and IP providers are offering and developing multicore products. In almost every case these products are aimed at improving computational throughput. The efficiency of these multi-CPU systems depends heavily on the ability to parallelize the instruction stream in order to divide the workload among the CPUs in the most efficient way possible. In terms of Computer Science this is an old problem whose solution has and continues to be refined through a series of commercial products.
Almost all the pundits that talk about multicore systems place the onus of parallelism squarely on the shoulders of the software developers and those who develop tools to aid in software development. And, for sure, some of this work must be done. But there are two other segments of the industry that need to also step up to the plate and take their rightful share of the burden: system architects and educators.
In the era of "System-on-Chip" I find that too many people still think of the system in the same way we used to think of a mainframe in the sixties and seventies: a computing engine. Systems need to do much more than just compute. They must manage data, they must input and output data, and they must manage inter process communications. I think that a more viable architecture is a system comprised of a number of application specific processors connected via a very high-speed serial connection. Most of these systems will be built from commercial IP blocks and few vendor specific hardware blocks by system houses, not semiconductor vendors. Therefore the EDA industry must be able to provide its customers with the ability to describe an heterogeneous system, abstract from it the portion that will be implemented in electronics, and then partition the resulting tasks among hardware and software blocks to arrive at an application specific system that fits a particular market requirement.
Colleges and universities need also do their part. We need courses that deal with multicore architectures, both from the software and the hardware point of view. And we need research in architectural issues specific to these kind of systems. What is obvious is that it is no longer possible to just be a hardware engineer or a software engineer. Interdisciplinary studies, encompassing both disciplines and even related fields are necessary to develop the skills required to achieve good partitioning of tasks within the system.
I expect that those DAC attendees focused in the present will want to talk about DFM and Power, while those looking into the needs for the next few years will want to debate multicore issues.