How Do You Verify a NoC?

Networks-on-chip (NoCs) are very configurable, arguably the most configurable piece of IP that you can put on a chip. The only thing that comes close are highly configurable extensible VLIW processors such as those from Tensilica (Cadence), ARC (Synopsys) and CEVA but Sonics would argue their NoCs are even more flexible. But this leads to a major challenge: how do you verify one of these beasts.

NoCs are defined by a configuration file. A NoC used to link perhaps a dozen blocks on an SoC but these days there may be a couple of hundred and the configuration file can be tens of thousands of lines long. This leads to the problem: how do you verify that the NoC RTL does indeed correctly represent the functionality defined by the configuration file. A big part of the problem is that everything is configurable. The protocols used, the performance, the connectivity, whether interfaces are blocking or non-blocking, how wide signals are. Everything. They are the Burger Kings of the SoC: have it your way.

The next level down a NoC consists of functional blocks connected by the actual signal buses. So the best approach is hierarchical, verify that each of those functional blocks does what it is meant to do and that they are hooked up correctly.

Like everyone else, Sonics uses constrained random verification, lots of SystemVerilog Assertions (SVAs) along with the constraints to ensure that the random vectors generated are themselves correct. Since the NOC is so configurable, these are not fixed files but also need to be automatically generated from the configuration file that specifies the NoC. Then vectors can be run and, hopefully, none of the SVAs fail (which would point to a problem).

But Sonics also does something other people do not: it also generates a SystemC transactional level model (TLM) corresponding to most blocks. These are still cycle accurate so not necessarily quite what you first think of when you hear TLM. The SystemC model contains protocol checkers (green in the diagram below) along with signal level adapters (light blue) to hook up the reference model. The light blue block on the left is the RTL block being verified.

The protocol checkers are a really important part of the verification environment. These monitor the signals going into and coming out of a block and verify that the protocols are implemented correctly.

Once the NoC is verified, that doesn’t guarantee that it works correctly on the SoC. Interface protocols are a sort of contract and the user’s IP blocks need to keep their side of the bargain. Once again a key part of the verification is the protocol checkers. These will call foul if an interface does not behave in line with the contract.

Sonics recommends that users keep the protocol checkers in place throughout the design process. They do not generate RTL so they don’t get designed into the chip itself. However during any RTL simulation they will catch many problems when they first occur rather than leaving them to show up as an obscure bug, perhaps on the other side of the chip many clock cycles later. In fact the first thing a Sonics AE will ask when a customer tries to report a bug in the NoC is whether the simulation has been run with all the protocol checkers turned on. Many bugs have gone away once this is done. What looked at first like an obscure bug in the NoC itself was actually caused by a completely different block violating the protocol.

The process just described is how to test a particular implementation of a NoC when designing an SoC. But that doesn’t help Sonics themselves check the whole tool chain. So every night they go one step further than constrained random. They generate random NoCs and then run the verification on them long enough to be confident that the implementation is correct. Then they generate another NoC and do it again. All night, every night.