|
|
|
|
|
|
 |
||||||||||
|
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
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:
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:
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:
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:
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:
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.
|
|
||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
