Sonics offers interconnect IP for AMBA AHB users

Sonics has created a solid place for itself in the upper reaches of complex SoC design. The company provides a tool that both helps architects analyze the interconnect needs of difficult SoCs and generates an interconnect structure as a synthesizable RTL file. The company has tracked the growing sophistication of multicore, multibus SoCs over the last few years, adding increasing sophistication to cope with growing needs for global coherency, non-blocking interconnect structures, and, of late, very high-performance DRAM channels. But in this pursuit, one concept that might have been obscured is good old-fashioned simplicity.

The needs of advanced SoC teams are not the needs of teams doing simpler designs. Yet given the economic times, Sonics recognizes that growth means appealing to these smaller teams as well. Jack Brown, Sonics senior vice president of sales and marketing, points out that today there are many SoC design teams who have lived quite happily up to now in a simpler world: AMBA bus architectures, maybe including an adventure into multilayer AHB, and either the delightful ARM interconnect-development tools or a conventional design flow.

But as these design teams take on their next projects, Brown contends, their design flow is running out of steam. It’s not that their existing tools are incapable of the job, so much as that the old tools force the users to deal with too much complexity. So Sonics is bringing its approach to interconnect architecture—you tell the tool about your data flows and it will generate the interconnect—to this level of design teams.

The product is called, catchily, SNAP—Sonics Network for AMBA Protocol. And the idea is pretty straightforward. SNAP provides a subset of the full Sonics tool, driven through a simple GUI that allows chip designers to describe their AMBA-based interconnect architecture. SNAP then generates an interconnect design based on the Sonics crossbar switch, generating AHB master layers and AHB/APB branches as necessary to interconnect the design teams existing blocks, without dealing explicitly with issues such as wrappers, bus protocols, endian issues, and so forth. Out comes synthesizeable RTL for the interconnect structure.

Brown emphasized that SNAP was not a tool for automating only the simplest chip designs. There are lots of other ways to do that. SNAP can handle up to 8 transport layers, with up to 8 CPU cores in each layer, and the interconnect SNAP generates will operate at up to 266 MHz in a 90 nm process. "This is a subset of our full technology," Brown said, "but not a trivial subset. In addition to handling up to 64 processor cores, the tool can support two levels of clock gating—coarse- and fine-grained, and provides links to power-management tools for power-gating or DVFS. It can support cache coherency across L1 caches, and using the AXI input structure can synchronize peripherals to the coherency scheme as well."

SNAP is available as a license for a single tape-out. Unlike Sonics’s larger tools, there is no royalty charged on the resulting design.

While SNAP may be aimed at a specific market opportunity, it may also be the first step in an increasing concentration on ease of use. Brown said that under the hood, SNAP uses XML to organize information about blocks and data flows. It would be a small step for Sonics to import XML IP descriptors in IEEE P1685 format and generate a proposed interconnect model automatically based on a simple block diagram, and on a few questions about computing loads and data flows in the programmable blocks.

That’s not to say automation will replace architects. The task of wringing the last drops of memory bandwidth out of a half-dozen interleaved DRAM channels in a multicore SoC is going to require hard work and clear thinking for the foreseeable future. But for less demanding designs just evolving out of the AHB world, SNAP could be a big time-saver.