Skip to Strategy + code metrics questions

Part 1 · Strategy and code metrics

Strategy + code metricsCoverage intent, traceability, and structural evidence

Connect requirements to measurable evidence and read statement, branch, condition, toggle, and FSM coverage without overclaiming correctness.

Question directory

Questions for Strategy + code metrics

Open an authored answer, then connect it to the evidence diagram and the related practice-bank prompt.

  1. Coverage strategyWhat is the difference between code and functional coverage?Coverage and closure
  2. Coverage strategyWhy is 100% code coverage not verification closure?Coverage and closure
  3. Coverage strategyWhat belongs in a useful coverage plan?Coverage and closure
  4. Structural diagnosticsHow do statement, branch, and condition coverage differ?Coverage and closure
  5. Structural diagnosticsWhy can toggle coverage be misleading?Coverage and closure
  6. Structural diagnosticsHow should unreachable RTL be handled?Coverage and closure

Coverage strategyTurn verification intent into evidence

Coverage is useful when every goal traces to a requirement or risk, samples a meaningful event, and complements a checker that establishes correctness.

Concept model

Four evidence systems, four different questions

  1. 01Requirementwhat must hold
  2. 02Observationwhat must occur
  3. 03Checkingwas it correct?
  4. 04Coveragewas it seen?
  5. 05Dispositionwhat remains?
EvidenceAnswersCannot prove alone
CodeWhat structure ran?Required scenarios
FunctionalWhat intent occurred?Correct results
CheckerWas behavior correct?Scenario completeness
Code
structure exercisedStatements, branches, conditions, toggles, and states.
Functional
intent observedPlanned values, transitions, scenarios, and combinations.
Checking
behavior judgedAssertions, scoreboards, and reference models detect errors.
Traceability
evidence justifiedEvery goal has a requirement, owner, target, and disposition.

Functional coverage records planned scenarios, code coverage exposes exercised implementation structure, and checkers decide correctness. Traceability explains why the combined evidence supports a requirement.

Strong answer

Code coverage reports exercised implementation structure. Functional coverage reports whether authored behaviors, values, transitions, and combinations were observed. Neither says by itself that the observed result was correct.

Reason it through

  • Code metrics are derived from RTL or other instrumented implementation constructs.
  • Functional goals are written from the specification, architecture, and risk analysis.
  • Assertions, scoreboards, and reference models provide the complementary correctness decision.
Practice a related question in the bank
Strong answer

Every instrumented construct can execute while important data combinations, orderings, error cases, or protocol outcomes remain absent or unchecked.

Reason it through

  • One statement execution can cover many semantically different behaviors only superficially.
  • Code coverage follows the implementation, so a missing requirement may have no RTL structure to measure.
  • Closure also requires checking quality, bug status, exclusions, and evidence for planned scenarios.
Practice a related question in the bank
Strong answer

Each item needs a requirement or risk, measurable observation, sampling definition, checker relationship, target, owner, and policy for unreachable or excluded behavior.

Reason it through

  • Use traceability to prevent goals from becoming disconnected from intent.
  • Define the denominator and sample event before regression data arrives.
  • Record ownership and review criteria so closure decisions are accountable.
Practice a related question in the bank

Structural diagnosticsRead code coverage without overclaiming

Code metrics reveal which implementation structures were exercised. They are powerful gap detectors, but a hit says nothing by itself about whether the behavior was intended or correct.

Concept model

Each metric illuminates a different structural blind spot

MetricA hit meansBlind spot
Statementoperation executeduntaken outcome
Branchdecision outcomemasked operand
ConditionBoolean influencesemantic scenario
Toggle0→1 and 1→0encoded values
FSMstate or arc visitedresult correctness
line hitif (valid) send();true ✓false ○
toggle hitmode[1:0]00→11 ✓01 never seen
Statement
operation ranDoes not prove every decision outcome occurred.
Branch
path selectedSeparates taken and not-taken control outcomes.
Toggle
0↔1 observedBit activity is not the same as semantic field coverage.
FSM
state + arcExposes unseen states and transitions in recognized machines.

A line may execute while one branch outcome never occurs, a condition may be masked, or an FSM transition may remain unseen. Diagnose the specific hole before changing stimulus or excluding logic.

Strong answer

Statement coverage records executed operations, branch coverage records control outcomes, and condition coverage examines Boolean operands or combinations that may be masked inside a taken branch.

Reason it through

  • An if statement can execute while only its true or false outcome is observed.
  • Short-circuit evaluation can prevent a subexpression from being independently exercised.
  • Tool definitions vary, so interpret the exact metric documented by the simulator.
Practice a related question in the bank
Strong answer

A bit may toggle because of reset or incidental traffic without exercising its intended function, while a multi-bit field can have full bit toggles and still miss important encoded values.

Reason it through

  • Independent 0→1 and 1→0 activity does not establish legal field combinations.
  • Reset activity should be distinguished from functional operating modes.
  • Use functional bins and checkers when the semantics live above individual bits.
Practice a related question in the bank
Strong answer

First establish why it is unreachable in the verified configuration. Remove dead logic when appropriate, or use formal evidence and a narrowly reviewed exclusion when the behavior is intentionally impossible.

Reason it through

  • Confirm the hole is not caused by a broken constraint or missing initialization sequence.
  • Scope exclusions to the exact construct and operating modes supported by the evidence.
  • Revisit the waiver when RTL, configuration, or assumptions change.
Practice a related question in the bank