Efficient Method to Compute Ignore Init Cycles For Debug bus/Connectivity Verification
Publication Date: 2017-Feb-09
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.
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 ...