SoC Connectivity Verification Nightmare

At the recent 2015 women’s World Cup soccer final in Canada, Japan was completely caught off guard in the first 15 minutes (and 4 seconds) by the USA. They were wary of the “set-piece” play by the USA team, which they were not able to defend against, resulting in the first three goals by the American women. However, the game breaker was the 54-foot midfield hat-trick goal from Carli Lloyd. To view this amazing goal click here.

A System-on-Chip (SoC) verification plan is like a defensive plan in soccer—marking key goal scoring players and preparing for set pieces, along with other creative moves by the opposition. Design verification engineers follow many best practices to avoid last-minute surprises and design re-spins. If these best practices and guidelines are not followed, it easily could result in a total disaster with soaring manufacturing costs and missed time to market windows, which are not fun in today’s competitive consumer markets.

The SoC verification plan is the focal point for defining exactly what needs to be tested, and drives the coverage criteria. Success of a verification team relies heavily on the completeness and accurate implementation of their verification plan. However, top level structural connectivity verification for design-for-test (DFT) or power management logic, along with mixed-signal IP, is usually not part of the original verification plan, especially for validating point-to-point connectivity and monitoring expected values of internal nodes for different modes of operation.

As seen in Figure 2, an SoC can have a staggering number of connections. The multitude of IP and design blocks used in an SoC comes from different sources. There could be legacy design blocks from previous designs, IP from 3rd party vendors, library components from an ASIC vendor, or design blocks from teams across geographies.

Figure 2: SoC with Hundreds of IP and Thousands of Connections

Generally the ownership for full chip integration is assigned to a few team members whose job is to validate the overall design-intent. This could come in the form of chip initialization routines, integration of I/O components (including SerDes blocks), or the validation of pipelining requirements between stages to support physical design and floor planning.

The verification of the core is typically part of the verification plan. However, the top-level connections are only tested with ad-hoc methods and often can result in last-minute surprises. One example of a point-to-point connectivity check is to make sure that all functional clocks to flip flops are driven from the output of clock gating cells (CGC). This is a structural check, and dynamic simulation would require dedicated tests, both at the IP-level and at the SoC level. Even with these laborious checks, it is still not exhaustive.

Atrenta’s SpyGlass tools, offer a creative way to validate point-to-point connectivity with easy and flexible capturing of “connectivity-intent”, which is portable across IP and SoC. See Figure 3 for an example. This solution can help verify “1 to 1”, “1 to many” or “many to 1” connections. Additionally, it can check for illegal conditions and help validate design methodology consistency across IP blocks, along with reuse “connectivity-intent” from IP at the SoC level.

The SpyGlass structural checks, supplement simulation based verification and can be executed along with other static RTL lint checks to quickly find basic connectivity bugs. These static checks allow running “regressions” for every change in functional RTL, while the violations clearly point to the failure root-cause, allowing the designer to quickly address the problem with a graphical user interface (GUI) based design analysis.

In soccer, defending set-pieces is a team effort and can be perfected through the use of highly skilled defenders. Likewise, the SpyGlass structural checks, complement the role of highly skilled designers, to avoid the verification nightmare of re-spins due to complex combinations of SoC connectivity.