Get email delivery of the Cadence blog featured here
Many products and methodologies are available for block-level verification, but system-on-chip (SoC) interconnect analysis is not so well served. At a recorded Cadence Theater presentation at the 2013 Design Automation Conference, Ravi Kalyanaraman, Verification Manager at Marvell Technology Group, spoke about his company's experience with interconnect analysis and discussed what he feels is needed.
Ravi first noted two key challenges that Marvell sees in SoC integration validation. One is incorrect handshake assumptions between IP blocks. Another is incorrect interconnect configurations, a problem that can severely affect system performance and may not be discovered until late in the design cycle.
Traditionally, Ravi said, integration validation has consisted of stitching IP blocks together and running a limited set of tests to find the "low hanging fruits" in terms of bugs. While this has been acceptable in the past, running a limited number of basic tests increases the risk of finding bugs late in the design cycle. "The limited time between bring-up and tapeout hardly gives any time for doing a thorough interconnect verification," he noted.
Traditional metrics give decent feedback on bus activity, but current approaches are "spatial" with very little temporal analysis, Ravi said. There are two problems with this. One is that protocol coverage gives very limited information because you are only dealing with a handful of integration tests. Another is that it is hard to measure the quality of tests supplied by the IP provider.
SoC integrators need some way of measuring and analyzing real-world stress on the system. One way to do this is to augment spatial analysis with temporal analysis. "Go deeper into what transactions are happening on the bus," Ravi said. "Start measuring temporal characteristics that are associated with the bus, such as requests and responses -- and at a higher level, performance and latency."
Marvell engineers came up with four key concepts for measuring bus activity. They are:
Ravi observed that a combination of spatial and temporal interconnect analysis can extract valuable information during functional verification. This includes qualitative factors such as determining whether streaming write bursts work only for one section of memory. It also includes quantitative factors such as the frequency of a given characteristic.
Beyond functional verification, interconnect analysis can facilitate performance analysis and architectural exploration, and help designers identify bottlenecks in the architecture. The interconnect configuration is more or less pre-set by the architect, Ravi noted, but typically there is no early feedback on such characteristics as latency. Interconnect analysis can close that gap and can provide some good feedback at a very high level of architectural exploration.
"When you integrate many IPs on a chip, how do you get feedback on the types of interconnect configurations you're trying?" Ravi asked. "If I turn the knobs on my interconnect in a certain way, am I getting better performance on one metric and seeing a drop in another? Today we are trying to do chip simulations the old-fashioned way to get this information, and very often this happens too late."
Ravi concluded with some results for the interconnect analysis that Marvell has done. He showed how engineers were able to find two performance bugs, adjust one test, and rewrite another test to work around a coverage hole.
A New Solution
Stewart Penman, principal solutions engineer at Cadence, took about one minute to talk about the Cadence Interconnect Workbench. He identified it as "an automation solution to enable verification and performance analysis of your interconnect." With it, he said, engineers can run simulation, analyze performance, tweak the interconnect configuration, and then re-analyze, running through this cycle much faster than was possible in the past.
Stewart noted that Interconnect Workbench starts with IP-XACT, builds a UVM testbench in SystemVerilog or the e language, and makes it possible to do both performance analysis and metric-driven verification.
To listen to the Marvell audio presentation and view the slides, click here. The presentation was given at 12:30 p.m. Tuesday June 4. For more information about Interconnect Workbench, see this previous blog post.