Light version of IP interconnects hardware blocks
By Ron Wilson, Executive Editor -- EDN, September 25, 2006
While it has been busy licensing its wares into some of the most influential platform designs in the industry, including Texas Instruments' OMAP (Open Multimedia Applications Platform) architecture, Sonics has been in an uphill battle to define the concept of interconnect IP (intellectual property). To some engineering minds, interconnect is a physical structure that results from layout and routing. To others, interconnect is a set of architectural decisions. Neither definition fits a traditional notion of IP. To further complicate things, Sonics provides not a core but a development environment, permitting architects to model a block-level-interconnect scheme at a rather abstract level and then nearly automatically move from the high-level model to an RTL (register-transfer level) implementation. To some engineers, this product seems a lot more like an EDA tool than like an IP core.
The current product, the Sonics MX (multiservice-exchange) interconnect IP includes a high-level modeling environment; a set of interface stubs that allow use of either Sonics' own OCP-IP (Open Core Protocol International Partnership) block wrappers or blocks with AMBA (Advanced Microcontroller Bus Architecture) AXI (Advanced Extensible Interface)- or AMBA AHB (Advanced High-Performance Bus)-compliant interfaces; and a toolkit of switched and shared-bus fabrics, buffers, and control blocks. The tool set weaves these hardware components into an interconnect structure that ties the user's hardware blocks in a way that meets the performance, power, and quality-of-service requirements that developers design during architectural simulation.
This approach has worked well for the most challenging SOC (system-on-chip) designs, in which both the number of blocks and the interblock-traffic requirements make the design highly complex. But the appeal has been less obvious to less complex designs—those CPU-centric chips with few processors that hover on the boundary between traditional ASICs and SOCs. As these designs get more complex, they start to benefit from the Sonics approach but still can't afford the overhead—either in silicon or financially—that makes sense on an extremely complex, high-margin chip.
To address what they feel is an emerging market in these less complex chip designs, the Sonics folks have come up with LX, a scaled-back version of MX. Many of the underlying hardware elements are the same, but the LX package offers what Sonics somewhat vaguely calls "a reduced set of design features." The aim is to produce interconnect structures for midsized SOCs that are appropriate in both space and power for the smaller problems the tools address but still convenient enough to the design team to justify the expenditure.
This approach may be a hard sell for some teams moving up from simple single-processor ASICs to moderately more complex designs. Such teams have typically developed some facility with AMBA or some other proprietary interconnect architecture and won't see the added value of an interconnect-generating tool. Yet, as these chip designers confront some of the system-level challenges of SOCs, such as optimizing access to a shared DRAM pool, guaranteeing quality of service, providing system-level exception handling, and offering hardware-level security that can meeting digital-rights-management requirements, they may find that just hooking the blocks together is only the beginning of the problem. In these cases, an architecture-level interconnect tool capable of RTL generation is indeed worth a look.
