by Gabe Moretti, Contributing Editor
It is important to notice how much network on chip (NoC) architectures have established themselves as the preferred method of connectivity among IP blocks. What I found lacking are tools and methods that help architects explore the chip topology in order to minimize the use of interconnect structures and to evaluate bus versus network tradeoffs.
Of course there are busses for SoC designs, most of which have been used in designs for years. The most popular one is the AMBA bus first introduced in 1996. Up to today there are five versions of the AMBA bus. The last one introduced this year is the AMBA 5 CHI (Coherent Hub Interface) that offers a new high-speed transport layer and features aimed at reducing congestion.
Accellera offers the OCP bus developed by OCP-IP before it merged with Accellera. It is an openly licensed protocol that allows the definition of cores ready for system integration that can be reused together with their respective test benches without rework.
The OpenCores open source hardware community offers the Wishbone bus. I found it very difficult to find much information about Wishbone on the OpenCores.org website, with the exception of three references to implementations using this protocol. Wishbone is not a complete bus definition, since it has no physical definitions. It is a logic protocol described in terms of signals and their states and clock cycles.
Other bus definitions are proprietary. Among them designers can find Quick Path from Intel, Hyper Transport from AMD, and IPBus from IDT.
IBM has defined and supports the Core Connect bus that is used in its Power Architecture products and is also used with Xilinx’s MicroBlaze cores.
Finally Altera uses its own Avalon bus for its Nios II products line.
Clearly the use of busses is still quite pervasive. With the exception of proprietary busses, designers have the ability to choose both physical and protocol characteristics that are best suited for their design.
Network on Chip
There are two major vendors of NoC solutions: Arteris and Sonics. Arteris is a ten year old company headquartered in Sunnyvale but with engineering center near Paris, France. its technology is derived from the computer networking solutions that are modified to the requirements of SoC realizations. Its products deal both with on-chip as well as with die-to-die and multi-chip connectivity.
Sonics was founded in 1996. In addition to network on chip products it also offers memory subsystems, and tools for performance analysis and development tools for SoC realizations. It offers six products in the NoC market covering many degrees of sophistication depending on designers’ requirements. SonicsGN is its most sophisticated product. It offers a high-performance network for the transportation of packetized data, utilizing routers as the fundamental switching elements. On the other hand SonicsExpress can be used as a bridge between two clock domains with optional voltage domain isolation. It supports AXI and OCP protocols and thus can be integrated in those bus environments.
After the panel discussion on IP Blocks Connectivity that covers mostly NoC topics, I spoke with Avi Behar, Product Marketing Director at Cadence. Cadence had wanted to participate to the discussion but their request had come too late to include them in the panel. But, information is important, and scheduling matters should not become an obstacle. So I decided to publish their contribution in this article.
The first question I asked was: on chip connectivity uses area and power and also generates noise. Have we addressed these issues sufficiently?
Avi:A common tendency among on-chip network designer is to over design. While it’s better to be on the safe side – under–designing will lead to the starvation of bandwidth hungry IPs and failure of latency critical IPs – over–designing has a cost in gate count and as a result in power consumption. In order to make the right design decisions, it is crucial that design engineer run cycle-accurate performance analysis simulations (by performance I primarily mean data bandwidth and transaction latency) with various configurations applied to their network. By changing settings like outstanding transactions, buffer depth, bus width, QoS settings and the switching architecture of the network and running the same, realistic traffic scenarios, designers can get to the configuration that would meet the performance requirements defined by the architects without resorting to over-design. This iterative process is time consuming and error prone, and this is where the just launched Cadence Interconnect Workbench (IWB) steps in. By combining the ability to generate a correct-by-construction test bench tuned for performance benchmarking (the RTL for the network is usually generated by tools provided by the network IP provider) with a powerful performance analysis GUI that allows side-by-side analysis of different RTL configurations, IWB greatly speeds this iterative process while mitigating the risks associated with manual creation of the required test benches.
What type of work do we need to do to be ready to have a common, if not standard, verification method for a network type of connectivity?
Avi: There are two aspects to the verification of networks-on-a-chip: functional verification and ‘performance verification’. Functional verification of these networks needs to be addressed at two levels: first make sure that all the ports connected to the network are compliant with the protocol (say AMBA3 AXI or AMBA4 ACE) that they are implementing, and secondly, verifying that the network correctly channels data between all the master and slave nodes connected to the network. As for performance verification, while the EDA industry has been focusing on serving the SoC architect community with virtual prototyping tools that utilize SoC models for early stage architectural exploration, building cycle accurate models of the on-chip network, capturing all the configuration options mentioned above is impractical. As the RTL for the connectivity network is usually available before the rest of the IP blocks, it is the best vehicle for performing cycle-accurate performance analysis. Cadence’s IWB, which as described in the previous answer, can generate a test bench tuned for running realistic traffic scenarios and capturing performance metrics. IWB can also generate a functional verification testbench which addresses the two aspects I mentioned earlier – protocol compliance at the port level and connectivity across the on-chip network.
What do you think should be the next step?
Avi: Many of our big SoC designing customers have dedicated network-on-a-chip verification teams who are struggling to get not only the functionality right, but ever more importantly, get the best performance while removing unnecessary logic. We expect this trend to intensify, and we at Cadence are looking forward to serving this market with the right methodologies and tools.
The contribution from Cadence reinforced the point of views expressed by the panelists. It is clear that there are many options available to engineers to enable communication among IP blocks and among chips and dies. What was not mentioned by anyone was the need to explore the topology of a die in view of developing the best possible interconnect architecture in terms of speed, reliability, and cost.