While communication between designers and foundries is a well-known problem of the deep nanometric age, still another communication problem cropping up is communications between various blocks in the SoC space. Interconnects inside chips provide such communications. Smaller geometries and multicore processors have concurred to make interconnects an important issue.
The wire variability, which was not a reckonable factor earlier, has to be accounted for in the latest designs. Considering the straight resistance and capacitance of wires, acceptable levels of variability have gone up from 10 percent at 0.25 and 0.18 micron nodes to 20 percent at 90nm nodes, and an estimated 30 percent at 65nm nodes. The interconnect IP needs to take into account these changes.
RE-USEABLE IP Designers can tweak a few percent here and there, but that has limited scope to solve problems, especially beyond 65nm. Some designers are thinking beyond conventional interconnects of wires. Building SoC with re-useable IP building blocks is seen emerging as one solution to the interconnect problem. This solution has the additional advantage of providing system-level functions, such as synchronization, address decoding, routing, and improved performance including bandwidth requirements, latency requirements, and the ability to deal with audio and video streams and real-time traffic.
Network-on-Chip (NoC) is yet another means of communications between individual blocks inside a chip. It solves the problem of scalability that is present in traditional point-to-point communications by using packet switching communications.
However, for all emerging alternatives formal specifications and standardization are necessary to document complex designs. I think from the standpoint of assembling an SoC, what is important is not what the fabric looks like, but standardization of the sockets and the ports where the IP interfaces with the connectivity fabric. Standardization has always been a nightmare, and designers should be prepared for it.
Multicore processors have been around for some time, but are not yet mainstream. Chip makers say that the future lies in multicore. Today the interfaces and tools used in multicore are generally proprietary. But as multicore becomes more common, new interconnect approaches may become necessary. The communications system in a multicore chip should provide for low latency, high bandwidth data movement, interprocess core synchronization, and a functionality range from streaming to messaging.
Dual-core chips today have a shared memory and bus. This architecture, though simple from a programming perspective, will not work when the number of cores increases, as the bus will become a bottleneck. A few types of interconnects that designers think can offset this disadvantage are multi-level buses, point-to-point, crossbars, mesh, NoC, etc. in different logical structures. Some advocate a combination of bus and other interconnect architectures on the same chip, as the bus simplifies transition of legacy code.
SOFTWARE TRANSPARENCY Regardless of the interconnect type, the software application should be transparent to different cores. Opinion seems to be veering toward having a unified API designed specifically for communications in a closely distributed embedded system, comprising multiple cores on a chip or multiple chips on a board. This API is insensitive to the type and number of cores, type of interconnects, and the operating system and logic topology.
To address the issues in the multicore industry, the Multicore Association was formed a year ago. This association is trying to come up with a standard communication API and CAPI specifically designed for embedded systems.
The time has come to talk about “communications-centric” designs. The important issue is not the functionality of each processor but the communications requirements for the different functionalities on the chip.
