SoC Interconnect Verification Challenge

François Cerisier and Mike Bartley, Test and Verification Solutions

Abstract :

With increasing numbers of CPU cores, multimedia subsystems and communication IPs in today’s System-on-Chips, the main SoC interconnects, crossbars or networks-on-chip fabrics become key components of the system.

In addition, IP reuse and Network-on-Chip (NoC) generation solutions have enabled the conception of new SoC architectures within a few months if not only weeks.

The verification of the SoC bus interconnects faces the challenge of verifying the correct routing of transactions as well as security and protection modes, power management features, virtual address space and bus protocol translations while still reaching project milestones.

This paper describes the author’s experiences in verifying multi-protocol SoC interconnects, it explains the pitfalls of such verification and describes a solution to allow easy reconfiguration of a generic verification environment. We show how issues have been resolved and propose a generic approach for SoC interconnect verification.

Foundation of Interconnect Verification

The foundation of the verification methodology proposes to verify the end to end transaction routes from a master interface to a slave interface.

This must include the following features

• Checking of the functional correctness of the transaction (scoreboard)
• Checking that the various protocols are being obeyed
• Adding additional verification constraints on to particular aspects of the interconnect (corner cases)
• Ways to measure the quality of the verification performed (coverage)

Whichever the interconnect implementation being used (full shared bus, arbiters, switches, NoC), the interconnect can be modeled as channels between master and slaves as shown in Figure 1 below.

Figure 1 – Interconnect Routes

The use of verification IPs (VIP) of the different protocols enables the generation of transactions through the interconnect, randomly covering the address space and the different interconnect routes.

Appropriate sequences automatically extracted from the address map also cover each valid and invalid segment min and max addresses.

Protocol checkers included with VIP automatically checks any protocol violation.

In order to verify the end to end transactions, we also need to implement an appropriate system scoreboard.

Verification Paradigm

One of the most common paradigms of verification is the cause to consequence effect.

In the interconnect verification methodology, this is translated to:

• A transaction which is sent from a master transits into the interconnect and is then received by the corresponding slave.
• Symmetrically, a transaction that is received by a slave, has to be related to a corresponding transaction which has previously been sent from a master interface.

Scoreboarding

Scoreboarding techniques are used to check that outputs of a design relates to a previous input.

The simplest scoreboard mechanisms could be implemented as FIFO of data or as hash arrays and are integrated in the verification environment as described in Figure 2 below.

Figure 2 – Basic Scoreboard Mechanism

Interconnect scoreboards should go beyond the data checking and should also check:

• Transaction content (address, direction, attributes)
• Transaction routes and check that transactions arrive at the correct destination
• Address translations
• Response codes

The implementation of an interconnect scoreboard requires to take in account each possible route of the SoC and the address map. Routes and address map configuration is therefore a key feature of a generic interconnect scoreboard.

Additionally, the scoreboard should report errors when transactions are not sent to the right interface or when transactions to an unmapped address do not get an error response.

Due to protocol conversions, there is not always a direct equivalence between different protocol opcodes. Transaction address alignments may also not be preserved. The interconnect scoreboard should therefore allow transaction address realignment between master and slave interfaces.

Security Management

Today’s interconnects include security management features. The basic of security management is to forbid unsecured transactions which target a secured area.

The scoreboard implementation should check this. Transactions that breach the security policy are not transmitted through the scoreboard and should receive an error response.

Power Management

Today’s complex SoC includes power management techniques to reduce power consumption. This includes dynamic switching on or off of the different IPs in the SoC.

When an IP is off, the interconnect may be configured to forbid direct access to this slave.

Either it get an error response from the interconnect (as in the security breach case) or the interconnect triggers an event to let the power management state machine to wake up the corresponding IP.

Power management features therefore add the following constraints to the verification environment:

• the interconnect scoreboard should provide support to the power management features
• The power up sequence should therefore be tested in these conditions, while stressing the bus with other transactions. The use of high level system sequence controlling the different VIP enables this verification.
• Proper functional metrics should be provided to ensure the conditions have been reached.

Virtual Address Space

MMU were initially used in CPU context to enable operating systems to allocate memory for each specific task, while avoiding different software to conflict on the same memory space. Since today’s SoC include more and more features that are now spread across different components in the system (e.g: multimedia chains), and because these tasks need to synchronize (e.g: using IPC) and share the same memory space, the virtual memory space of the CPU is moved or duplicated to the system level. Some interconnects therefore include virtual address mapping. This could be either through a simple mapping table or through a MMU-like mechanism.

The scoreboard implementation should take this in account and allow dynamic reconfiguration of the address translation table, so that transactions continue to be checked against their expected routing.

System Cache

Additionally, memories are now no longer accessed only by the main CPU. This has led recent SoC architectures to integrate caches at system level or within a SoC interconnect.

ACE Protocol for instance adds features for cache coherency to synchronize caches.

However internal cache memories or cache coherency protocols no longer preserve the interconnect verification paradigm earlier described. For instance, cache coherency protocols may not complete a transaction to its targeted destination in case the information already exist in another cache. Scoreboard implementation therefore needs to be extended in order to take this into account.

Dynamic Re-Configuration and Uncertainties

One issue with dynamic configuration (security, power, memory, routes) of NoC is that the configuration could change while transactions are still being transmitted. In practice, the operating system should follow clear sequences prior to change the interconnect configuration. For instance, when switching off a memory controller, the OS should make sure there is no more traffic from DMAs or video streams to this memory.

This impacts the interconnect verification in the following ways:

• Semaphores should be implemented so that the random generation of the VIP are dynamically constrained such that transactions are not generated during the configuration switch.
• Or the scoreboard should implement further algorithm to deal with uncertain states.

Dynamic Constraints

Constrained Random Generation of VIPs automatically generates transactions from different masters. We then rely on the scoreboard to check that all transactions are received properly and by the right interface.

In constrained random generation, some of the random parameters are the delays between transactions or sequences. Controlling these delay stresses the interconnect and all its logics differently Figure 3).

Figure 3 - Static delay constraints

However these random values are statically stable and can lead to the opposite expected effect. For instance, if an arbiter is using a fix priority scheme, the most priority port might be selected until the 0 dealy sequence finishes. Hence, the arbiter switch will not be stressed. Transactions coming from different masters are not interleaved and the interconnect is not stressed.

This problem can be solved by implementing dynamic constraints that change over time (see Figure 4).

Figure 4 – FIFO counter history using dynamic constraints

Protocol conversion and error response checking

Even though a transaction is properly reaching the slave interface of an IP, the slave may still issue an error. This error code should be properly propagated through the interconnect back to the master. The interconnect scoreboard therefore also implements an error response checking mechanism on the error response.

As shown in Figure 5, due to the fact that protocol conversions may not preserve transaction atomicity, special checking of error responses should be implemented.

Figure 5 - Master/Slave Error Response Relationship

Automating Interconnect verification

Building the verification environment for an interconnect requires to setup different VIPs to generate transactions onto the different interfaces. A generic scoreboard can be implemented and connected to any kind of bus VIP and be independent of any protocol.

The author’s experiences in developing such scoreboard has shown that the right architecture has enabled adding low power management features, security management and virtual address translation without code rewrite.

The main features of the implemented generic interconnect scoreboard are:

• address mapping configuration
• route configuration
• protocol independence to allow any kind of masters or slaves
• full transaction content checks, including address, data, attributes
• response checks
• security and power management support
• configurable address translation table
• hook functions to add new features in future
• functional coverage metrics on routes, memory segments, transaction kinds, responses and cross coverage metrics

Such development has enabled the author to switch to new interconnect projects within days and automate 80% of the verification targets. The 20% remaining verification targets being mostly the corner cases and the power management features which require dedicated test sequences.

Conclusion

Verifying a system interconnect goes far beyond transaction route checking. This paper shows technical details that make the interconnect verification a special verification case, traps that should be avoided and features that the verification environment should consider before starting. These point being identified, it is possible to implement a verification environment which can be configurable and automate the verification of different SoC architectures.