SystemC Co-Simulation of NoCs and IP Blocks

Verification in general suffers from a couple of fundamental problems. Availability of models and performance of different levels of representation.

The first problem, availability of models, is that you would like to start verification as soon as possible but all the representations are not ready early enough. Obviously it is impossible to verify the RTL before writing the RTL, but you may still need to do some simulation of the block to design other parts of the chip.

The second problem, performance, is that it is very difficult to get more than a factor of 10 or 20 out of a representation by discarding detail rather than using a completely different model. You can throw away as much detail as you like in a gate-level representation and you won’t get an RTL simulation. If SPICE simulations ran as fast as emulators then we might not bother with any intermediate representations but obviously they don’t. They can’t even get close to gate-level performance.

As chip design has morphed over the last decade or two from building everything from scratch to integrating IP blocks, the verification problem has got more complex. You would like to verify architectural level performance early in the design cycle. After all, there is little point in going to the effort of assembling the IP blocks if you can tell in advance that the performance will be inadequate.

Another verification challenge is to avoid consuming too much simulation bandwidth on the known-correct parts of the design in order to verify the parts that are still being validated. For example, doing RTL simulation of an entire SoC to validate a single block of RTL is not a good tradeoff of simulation resources.

Many, if not most, advanced SoCs now handle the connectivity of the IP blocks using network-on-chip (NoC) technologies such as those available from Sonics, ARM and others. This means that the IP blocks on the SoC are mostly interconnected through the NoC. One attractive level of simulation is using SystemC. There are actually multiple layers of SystemC although with careful design much of the code can be shared.

Sonics has been creating SystemC IP models since 2005. Initially this was just for performance modeling and functional verification of the NoC itself, but since 2010 they have also provided TLM 2.0 models with OCP/AXI sockets. These models provide their customers with architectural executables for performance/complexity tradeoffs, and also fast models to validate performance on realistic NoC traffic scenarios. This makes it possible to analyze things like bandwidth and latency versus system power, arbitration, buffer sizing and other factors that affect performance, power and area (PPA).

Sonics SystemC models are written to be cycle-accurate. The reason for this is that in a NoC, mico-architectural subtleties (such as missed cycles) can affect performance unduly. While other blocks on an SoC can be modeled approximately, interconnect performance is too central to give up accuracy. The interaction of the NoC with overall system performance is further complicated by features such as clock gating, automatic power-down and wake-up and that have major high-level effects.

Under the hood of Sonics models are equivalence checkers (EC) that ensure that the behavior of the hardware being simulated matches the protocols and catches blocks that “misbehave” and violate some aspect of the protocol (such as sending a message when they should not, or sending a message to an incorrect block). In essence, this compares behavior to the underlying reference model.

Modeling at this level allows co-simulation with models of the IP blocks at different levels, making good use of simulation cycles and allowing investigation to take place at levels from architecture down to RTL verification.

Sonics gave a presentation on co-simulating their NoCs with Cadence’s Incisive at CDNLive earlier this month. The presentations for this year’s conference are not yet on Cadence’s website, but the CDNLive page where they will presumably eventually appear is here.