Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Efficient Method to Compute Ignore Init Cycles For Debug bus/Connectivity Verification

IP.com Disclosure Number: IPCOM000249192D
Publication Date: 2017-Feb-09
Document File: 7 page(s) / 196K

Publishing Venue

The IP.com Prior Art Database


Connectivity checking — the verification of device wiring — is among the many unheralded, yet essential, tasks in semiconductor design verification. In a nutshell, it is making sure that the connections between blocks of logic behave as intended. The trace and debug bus is a global on-chip bus that enables observation of internal signals for post-silicon debugging and performance monitoring. Templates provide a more concise description of the trace bus using primitive blocks that closely correspond to the typical logical elements comprising such a bus, albeit at a higher level of abstraction than a highly tuned implementation of the buses. As stated, due to inherent differences in initial values and latch types between the reference implementation of the debug bus specification, and the actual logic implementation, this will often result in transient failures during the initial several timeframes from reset. This is a complicated issue in practice. We present two high performance algorithms : (1) for verifying a template under automatically-derived minimal “ignore initial cycles” value. (2) for computing the “ignore initial cycles” value using transient detection algorithm.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 15% of the total text.


Efficient Method to Compute Ignore Init Cycles For Debug bus /Connectivity Verification

Connectivity checking — the verification of device wiring — is among the many unheralded, yet essential, tasks in  semiconductor design verification. In a nutshell, it is making sure that the connections between blocks of logic  behave as intended. This is not a trivial undertaking as such connections can easily number in the thousands, and  span very large design components. 

The trace and debug bus is a global on‐chip bus that enables observation of internal signals for post‐silicon  debugging and performance monitoring. These buses are often configurable in terms of which signals are  monitored (often projected to data slices, e.g. 128 bit vectors) through the buses. The trace bus represents a  major challenge for verification, because the available specification of behavior itself can be ambiguous or  incorrect; a straight forward approach to use directed testcases would be extremely time consuming and  inherently incomplete (coverage gaps risk failure to identify logic or specification bugs); and the large size of the  corresponding logic coupled with sequential depth of the design make formal verification approaches difficult.  

To facilitate the correctness specification of debug buses, a high‐level specification language called a “template”  has been devised and used for several project generations that allows a simple and concise description of such a  bus. This template specification is used for both documentation, as well as input for automated formal testbench  creation. As with the use of any concise formal specification language, the use of this language minimizes the risk  of specification errors, which are awkward to specify using standalone property specification languages such as  PSL (Property Specification Language).  

Templates provide a more concise description of the trace bus using primitive blocks that closely correspond to  the typical logical elements comprising such a bus, albeit at a higher level of abstraction than a highly tuned  implementation of the buses.  In addition, the template specification is hierarchical, i.e. one can reuse the  templates specified lower in the hierarchy when verifying buses incorporating these at higher points in the  hierarchy.  Figure 1 depicts  an example template file specification. 

#! DEBUG BUS top_bus(0:8) #! DESIGN ENTITY example_top_mac

MODE top_sel.l2(0) 0    top_sig1(0:8)  0:8  1

MODE top_sel.l2(0) 1 MODE inst_sel.l2(0) 0    top_sig2(0:8)  0:8  1

Figure 1: Example Template file specification

Where top_bus  indicates the name of the trace bus signals to be checked for properly routing the monitored  signals, and MODE signals (top_sel.l2(0) and inst_sel.l2(0)) provide the configuration condition under which a  corresponding trace signal is monitored.  top_sig1(0:8) and top_sig2(0:8)  are the monitored trace signals.  Each  monitored trace signal is also associated with a mapping to bits ...