Verification, Testing, Reliability, and Security

Introduction

Digital logic design does not end when a circuit produces the expected truth-table outputs. A design must also be shown to behave correctly under realistic operating conditions, to tolerate faults where required, to remain dependable over its service life, and to resist deliberate misuse. Verification, testing, reliability, and security therefore form a connected engineering discipline.

Verification asks whether the design satisfies its specification. Testing asks whether an implemented circuit contains manufacturing or operational defects. Reliability concerns the probability that the circuit continues to perform correctly over time. Security addresses unauthorized observation, modification, activation, or denial of service. Documentation governance provides the evidence that these claims were systematically established and maintained.

These concerns are especially important in embedded controllers, communication equipment, medical devices, industrial automation, vehicles, and safety-critical systems. A low-cost consumer product may tolerate occasional failure, whereas an aircraft controller or infusion pump requires traceable evidence, fault containment, and carefully controlled changes.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Explain the purposes and levels of digital design verification.
2. Develop testbenches, test cases, assertions, and useful coverage measures.
3. Distinguish functional verification from timing verification.
4. Apply common fault models and design-for-test techniques.
5. Estimate basic reliability and explain redundancy and fail-safe operation.
6. Identify hardware security threats and propose secure design measures.
7. Apply documentation, configuration control, and review practices to verification evidence.

1. Verification as an Engineering Activity

1.1 Verification and validation

Verification determines whether an implementation conforms to its stated requirements: “Did we build the product right?” Validation determines whether the product meets the intended user or system need: “Did we build the right product?” A circuit can be verified against an incorrect specification and still fail validation.

Verification occurs at several abstraction levels:

Simulation is valuable but not sufficient. A simulator evaluates selected input sequences under a model. It cannot prove that untested behavior is correct unless formal methods or exhaustive reasoning are applicable. Hardware-in-the-loop testing, laboratory measurements, static analysis, formal property checking, and production tests complement simulation.

1.2 Requirements as the foundation

A testable requirement identifies an observable behavior and its conditions. “The controller shall respond quickly” is weak because “quickly” is undefined. “After a valid request sampled on the rising clock edge, the controller shall assert acknowledge within two clock cycles” is testable.

A useful requirement record includes:

• unique identifier;
• source and rationale;
• normal and exceptional conditions;
• measurable acceptance criteria;
• verification method;
• responsible reviewer; and
• links to tests, results, and defects.

Traceability connects requirements to design elements, test cases, results, and corrective actions. It prevents a common failure mode in which extensive testing is performed but an important requirement is never addressed.

2. Testbenches and Test Cases

2.1 Testbench structure

A testbench is the environment used to stimulate and observe a design under test (DUT). A practical digital testbench commonly contains:

1. Stimulus generator: produces clocks, resets, commands, data, and fault conditions.
2. Driver: converts abstract transactions into signal-level inputs.
3. DUT: the circuit or module being evaluated.
4. Monitor: observes outputs and protocol events.
5. Reference model or predictor: calculates expected behavior independently.
6. Scoreboard: compares expected and actual results.
7. Assertions: detect prohibited or required temporal behavior.
8. Coverage collector: records which scenarios and structures were exercised.
9. Report and control mechanism: identifies pass, fail, timeout, and reproducibility information.

The reference model should be simpler and independently reasoned where possible. Reusing the same algorithmic error in both DUT and model can make a test appear successful while both are wrong.

2.2 Test-case design

A test case should state its purpose, preconditions, input sequence, expected result, pass criteria, and cleanup or reset behavior. Effective test selection includes:

• nominal cases, such as valid commands and ordinary data;
• boundary cases, such as zero, maximum values, rollover, and minimum pulse width;
• illegal cases, such as invalid opcodes or unsupported states;
• transition cases, such as reset during an operation;
• concurrency cases, such as simultaneous requests;
• timing cases, such as setup, hold, latency, and back-to-back transfers;
• fault-injection cases, such as stuck signals or corrupted parity; and
• random or constrained-random cases that explore combinations not manually anticipated.

A test should fail for a meaningful reason. Tests that merely observe internal signals or depend on arbitrary simulation delays are often fragile and provide weak evidence.

2.3 Example: verifying a four-state controller

Consider a controller with states IDLE, LOAD, RUN, and ERROR. Requirements include:

• reset places the controller in IDLE;
• a valid start command from IDLE enters LOAD;
• completion from LOAD enters RUN;
• an illegal condition enters ERROR;
• ERROR remains latched until reset; and
• no state transition occurs without a clock edge.

A strong test plan includes one test for each legal transition, one test for every state, an illegal-condition test, reset during each state, repeated start commands, and checks that outputs correspond to the current state. A temporal assertion can express the last requirement conceptually: if the controller is in ERROR, then it must remain in ERROR until reset. The testbench should also check that no output changes unexpectedly between active clock edges.

2.4 Assertions and coverage

An assertion is an executable statement of expected behavior. A safety assertion states that something bad never occurs, such as “read and write enables are not simultaneously active.” A liveness assertion states that something good eventually occurs, such as “a request is eventually acknowledged,” subject to stated assumptions.

Coverage must be interpreted carefully:

• Code coverage records executed statements, branches, conditions, expressions, or toggle activity.
• Functional coverage records whether intended behaviors, combinations, and scenarios occurred.
• Assertion coverage records whether properties were evaluated and, where applicable, exercised in meaningful ways.
• Mutation coverage measures whether deliberately injected faults are detected by the test suite.

High code coverage does not guarantee correct functionality. A test can execute every line while never checking the resulting outputs. Coverage closure should therefore mean that requirements and meaningful behaviors are exercised, exceptions are explained, and unhit items are either tested or formally justified as unreachable.

3. Functional and Timing Verification

3.1 Functional verification

Functional verification evaluates logical behavior independent of physical implementation details. It checks truth tables, state transitions, arithmetic results, protocol ordering, reset behavior, error handling, and interface contracts.

For combinational logic, verification should include all relevant input combinations or a justified representative set. If a circuit has n independent binary inputs, exhaustive input enumeration contains 2ⁿ combinations. This becomes impractical rapidly; for 20 inputs, it would require 1,048,576 combinations. Partitioning, equivalence checking, symbolic reasoning, and constrained-random testing are then useful.

For sequential logic, the state space includes both input combinations and prior state. Tests should therefore address sequences, not merely isolated vectors. Reset assumptions must be explicit: synchronous reset is sampled on a clock edge, while asynchronous reset can affect state independently of the clock.

3.2 Timing verification

A logically correct circuit may fail if signals do not arrive within the required time. Important timing concepts include:

• Propagation delay: time between an input transition and the corresponding output transition.
• Contamination delay: earliest time at which an output may begin to change.
• Setup time: minimum interval for which data must be stable before a receiving clock edge.
• Hold time: minimum interval for which data must remain stable after that edge.
• Clock-to-Q delay: time from a flip-flop clock edge to a change at its output.
• Clock skew: difference in clock arrival time at two sequential elements.
• Jitter: short-term variation in clock timing.
• Slack: available timing margin after subtracting required delay from allowed delay.

For a simple register-to-register path, a common setup constraint is:

Here T_clk is the clock period, t_cq(max) is maximum clock-to-Q delay of the launching register, t_pd(max) is maximum combinational path delay, t_setup is receiving-register setup time, and t_skew and t_jitter represent worst-case timing uncertainty under the chosen sign convention. The formula assumes a single synchronous clock domain and no special timing exception. It is a simplified constraint; actual sign conventions and clock relationships must follow the analysis tool and technology documentation.

The maximum ideal clock frequency is approximately:

where f_max is in hertz when T_clk is in seconds. For example, if the total required period is 10 ns, f_max is approximately 100 MHz. This calculation does not by itself account for power, clock uncertainty beyond the stated margin, or other paths.

Hold verification concerns the earliest data arrival. A simplified hold condition is:

where t_cd(min) is minimum contamination delay and t_hold is the receiving flip-flop hold requirement. Setup and hold failures are not corrected in the same way: reducing maximum path delay helps setup, whereas adding controlled delay or changing clock relationships may help hold.

Static timing analysis examines timing paths without applying simulation vectors. It is efficient for digital synchronous paths, but it depends on accurate constraints, libraries, generated-clock definitions, false-path declarations, and operating corners. An incorrectly constrained design can receive a misleading “clean” result.

3.3 Metastability and clock-domain crossing

When an asynchronous signal or a signal from another clock domain is sampled near a receiving clock edge, the receiving flip-flop may enter metastability. Its output may take an unpredictable time to settle. Metastability cannot be eliminated completely by ordinary digital logic; its probability can be reduced by synchronizer stages, suitable protocols, and adequate settling time.

A two-flip-flop synchronizer is commonly used for a single-bit control signal, with the first stage exposed to possible metastability and the second stage used by downstream logic. Multi-bit data requires stronger methods, such as handshaking, gray-coded counters, or asynchronous FIFOs. Verification must check that clock-domain crossing structures are present and that no unsafe combinational crossing has been overlooked.

4. Fault Models and Design for Test

4.1 Fault, error, and failure

A fault is a physical or logical defect, such as a short circuit or incorrect transistor connection. An error is an incorrect internal state or signal caused by a fault. A failure is an externally observable departure from required service. A fault may remain dormant if it is never activated or observed.

Common digital fault models include:

A model is an abstraction, not a complete physical description. Tests that detect all modeled stuck-at faults may still miss delay defects, analog marginality, crosstalk, or a new defect mechanism.

4.2 Controllability, observability, and testability

A node is controllable if a tester can establish desired values at that node. It is observable if the effect of its value can reach an accessible output. Testability improves when internal nodes can be controlled and observed with reasonable test effort.

Design-for-test (DFT) techniques include:

• Scan chains: flip-flops are connected into shift registers so internal state can be loaded and unloaded.
• Built-in self-test (BIST): the circuit generates test patterns and analyzes responses internally.
• Boundary scan: standardized serial access tests package pins and board interconnections.
• Memory BIST: dedicated logic applies algorithms to memory arrays.
• Test points: additional control or observation points improve fault detection.
• Compression: compacts many responses into a smaller signature, reducing tester data volume.

Scan testing usually has a shift mode and a capture mode. During shift, test data enters the chain. During capture, the combinational response to applied values is stored. The captured response is then shifted out and compared with an expected signature. DFT adds area, power, routing, and security considerations, so test access must be controlled in deployed products.

4.3 Test quality

Fault coverage is commonly expressed as:

The equation applies only to the selected fault list and test assumptions. A high percentage is not a guarantee of field quality. Test escape, tester limitations, unmodeled defects, and environmental effects remain possible. Diagnostic resolution is also important: detecting that a fault exists is different from identifying its location.

5. Reliability, Redundancy, and Fail-Safe Design

5.1 Reliability concepts

Reliability is the probability that an item performs its required function for a specified time under stated conditions. It differs from availability, which also considers repair and restoration. Reliability engineering requires a mission definition, operating environment, failure criteria, and time interval.

For a component with a constant failure rate λ, the exponential reliability model is:

where R(t) is reliability over time t, λ is the constant failure rate in failures per unit time, and e is the base of natural logarithms. The model assumes statistically independent failures and a constant hazard rate, conditions that may not hold during early-life defects or wear-out.

The mean time to failure under this model is:

MTTF is an average, not a guarantee or a time at which all components fail. For independent components in a series system, every component must operate for the system to operate:

If two independent components each have reliability 0.99 for a mission, series reliability is 0.99 × 0.99 = 0.9801. Independence is a strong assumption; common power, temperature, design, or manufacturing causes can invalidate it.

For two identical independent components in parallel, where either can perform the function:

If each has reliability 0.99, the result is 1 − 0.01² = 0.9999. This improvement exists only if failures are sufficiently independent and the system can detect, isolate, or tolerate the failed unit.

5.2 Redundancy and voting

Redundancy may be:

• Active: all units operate and their outputs are combined.
• Standby: a spare is activated after detecting a primary failure.
• Information redundancy: parity, error-correcting codes, or checksums add information for detection or correction.
• Temporal redundancy: an operation is repeated and results compared.

A triple-modular-redundant system uses three channels and a voter; it can mask one incorrect channel if the voter and remaining channels function correctly. However, redundancy can increase common-cause vulnerability, power consumption, complexity, and the number of possible failure interactions.

5.3 Fail-safe and fault-tolerant operation

A fail-safe system moves to a state that minimizes hazard when a fault occurs. A railway signal becoming restrictive after loss of power is a familiar conceptual example. A fault-tolerant system continues providing required service despite specified faults, often through redundancy and reconfiguration. These are not identical: a system that safely shuts down is fail-safe but not necessarily fault-tolerant.

Safety mechanisms include watchdog timers, safe-state encoding, interlocks, plausibility checks, lockstep comparison, error detection, current limiting, and independent shutdown paths. A safe-state decision must be derived from hazard analysis; simply assigning zero to every output is not universally safe.

6. Hardware Security and Secure Digital Design

6.1 Threats

Hardware security threats include:

• unauthorized access to debug or test ports;
• extraction of intellectual property from scan chains or memory;
• fault injection using voltage, clock, electromagnetic, laser, or temperature disturbances;
• side-channel analysis of power, timing, or electromagnetic emissions;
• counterfeit or modified components;
• malicious logic insertion in the supply chain;
• hardware Trojans that activate under rare conditions;
• firmware replacement through insecure boot paths; and
• denial of service through resource exhaustion or unsafe inputs.

Security goals are commonly expressed as confidentiality, integrity, and availability. Authenticity, accountability, and non-repudiation may also be important in system contexts.

6.2 Secure design principles

Security should be designed from requirements rather than added after verification. Important principles include:

1. Least privilege: expose only the access needed for a function.
2. Defense in depth: combine independent controls rather than relying on one barrier.
3. Secure boot: verify the authenticity and integrity of code before execution.
4. Measured or authenticated updates: accept updates only through controlled cryptographic verification.
5. Debug-lock control: disable or strongly authenticate production debug access.
6. Key protection: use protected key storage and avoid hard-coded shared secrets where possible.
7. Fault-aware checks: detect abnormal voltage, clock, sequence, or control conditions.
8. Constant-time or balanced implementations where appropriate: reduce information leakage from data-dependent timing or power.
9. Lifecycle management: distinguish development, manufacturing, deployment, maintenance, and retirement states.
10. Fail-secure behavior: when access control fails, deny unauthorized access without creating an unsafe physical condition.

Security and safety can conflict. For example, locking a controller after detecting tampering may protect data but could be hazardous if the controller operates a critical actuator. System-level hazard and threat analyses must therefore be performed together.

6.3 DFT and security tension

Scan access improves observability and manufacturing diagnosis but may reveal secret internal state. Production designs may use scan authentication, scan data masking, limited scan access, secure lifecycle states, or encryption of test data. These measures must not be treated as substitutes for a complete threat model. Test infrastructure, vendor access, programming stations, and discarded devices are all part of the attack surface.

Artificial intelligence can assist verification by generating input sequences, identifying coverage gaps, clustering failures, or suggesting assertions. It does not replace engineering judgment: generated tests may repeat known patterns, miss security properties, or encode an incorrect reference model. AI tools used with proprietary RTL or security-sensitive designs also create confidentiality and governance concerns.

7. Documentation Governance and Evidence

Verification evidence must be reproducible. A credible project records tool versions, source revisions, constraints, libraries, seeds for randomized tests, environmental assumptions, test results, waivers, defects, and approvals. Configuration management ensures that a reported result can be recreated against the exact design and verification inputs that produced it.

A practical governance workflow is:

1. Baseline requirements and acceptance criteria.
2. Review architecture, hazards, threats, and verification strategy.
3. Link requirements to tests and properties.
4. Run automated regression tests under controlled configurations.
5. Triage failures and record root causes.
6. Review coverage and justify exclusions.
7. Perform independent sign-off for safety- or security-critical claims.
8. Archive reports, logs, waveforms, and tool metadata.
9. Control changes through impact analysis and re-verification.
10. Maintain a living record through deployment and maintenance.

A waiver is not an erasure of a failure. It is a documented decision that an item is understood, bounded, and acceptable under stated reasoning and authority. Weak governance often converts uncertainty into an unjustified claim of completion.

8. Illustrative Case: Secure Controller for an Industrial Pump

Background

An illustrative manufacturer develops a digital controller for an industrial cooling pump. The controller receives a start command, monitors temperature and flow, drives a motor contactor, and reports status over a network. Loss of flow while the motor is active can damage equipment.

Problem

Initial functional simulation passes normal start and stop sequences. However, review identifies three risks: a reset may occur during operation, an attacker may access the maintenance debug port, and a clock-domain crossing may corrupt a flow alarm.

Analysis

The team creates requirements for safe shutdown, alarm latency, authenticated maintenance access, and synchronizer behavior. The test plan includes boundary temperatures, loss of flow, reset in every operating state, repeated network commands, and malformed packets. Timing analysis is performed for the motor-control path and for the alarm crossing between unrelated clocks.

A two-stage synchronizer is used for the single-bit flow alarm. The controller enters a safe stopped state when a validated alarm is received. The debug port is disabled in the production lifecycle state and requires authenticated authorization in service mode. A watchdog detects software or control-path nonresponse, while independent hardware logic removes the motor-enable signal when a critical alarm persists.

Verification and outcome

Simulation confirms legal transitions and safe-state behavior. Assertions detect simultaneous motor enable and critical alarm, missing acknowledgements, and illegal state encodings. Fault injection demonstrates detection of stuck-at control signals and corrupted network fields. Static timing analysis identifies insufficient setup margin on one path; reducing combinational depth restores positive slack. The team also tests clock-domain crossing assumptions rather than relying only on ordinary functional vectors.

The result is not merely a passing simulation. It is a documented argument linking hazards and threats to design mechanisms, tests, timing evidence, fault assumptions, and controlled production access.

Learning points

• Normal-case tests do not establish safety.
• A fault model must be selected consciously and supplemented where necessary.
• Security controls must account for lifecycle and maintenance access.
• Independent mechanisms are valuable when a single failure could create a hazard.
• Traceability turns technical activity into reviewable engineering evidence.

9. Challenges and Limitations

No verification campaign can examine every physical condition. Simulation models may omit analog effects, package behavior, radiation, aging, or undocumented tool assumptions. Formal verification can prove a property only within its model, assumptions, and explored state space. Random testing can find unexpected interactions but may spend most of its effort in uninteresting regions. Coverage metrics can be gamed if teams optimize the number rather than the meaning of tests.

Reliability calculations based on constant failure rates may be inappropriate during burn-in or wear-out. Redundancy can fail through common causes. Security controls age as attackers discover new techniques. Test access may be necessary for manufacturing but dangerous in the field. These limitations justify layered assurance, independent review, conservative assumptions, and continuous monitoring rather than reliance on a single metric.

Best-Practice Checklist

• Write measurable, unambiguous requirements.
• Build a verification plan before implementation is complete.
• Use both directed and constrained-random tests where appropriate.
• Separate the reference model from the implementation.
• Combine simulation, assertions, formal analysis, timing analysis, and hardware testing.
• Test reset, illegal inputs, boundary values, concurrency, and faults.
• Treat timing constraints and clock-domain crossings as first-class design concerns.
• Select fault models that reflect the technology and application.
• Control production test and debug access.
• Analyze common-cause failures before claiming redundancy.
• Preserve traceable, reproducible evidence under configuration control.
• Reassess reliability and security when requirements or components change.

Chapter Summary

Verification establishes that a digital design conforms to its requirements, while validation considers whether those requirements meet the intended need. Effective verification combines well-defined requirements, structured testbenches, independent reference models, assertions, functional coverage, formal reasoning, timing analysis, and physical testing. Functional correctness is distinct from timing correctness; setup, hold, clock uncertainty, and clock-domain crossing must be evaluated explicitly.

Fault models such as stuck-at, bridging, transition, coupling, and memory faults support systematic testing, while scan chains, boundary scan, BIST, and test points improve controllability and observability. Reliability analysis uses models such as R(t) = e^(−λt) only under stated assumptions. Redundancy may improve reliability but introduces complexity and common-cause risks. Fail-safe design minimizes hazards after faults, whereas fault tolerance maintains service through specified faults.

Hardware security requires protection of test interfaces, debug ports, keys, boot paths, supply chains, and physical attack surfaces. Safety and security must be analyzed together. Finally, documentation governance, traceability, configuration control, independent review, and reproducible evidence transform verification from an informal activity into a defensible engineering process.

Key Terms

Verification: Evaluation of whether an implementation satisfies specified requirements.

Validation: Evaluation of whether a product meets its intended purpose and user need.

Testbench: Environment that stimulates, observes, and evaluates a design under test.

Design under test (DUT): Circuit or module being evaluated.

Assertion: Executable statement expressing required or prohibited behavior.

Functional coverage: Measure of exercised intended behaviors and scenarios.

Propagation delay: Time from an input transition to the corresponding output response.

Setup time: Required data stability interval before a clock edge.

Hold time: Required data stability interval after a clock edge.

Metastability: Temporary unpredictable state caused by an insufficiently timed sampling event.

Fault model: Abstract representation of a physical or logical defect.

Scan chain: Test connection that permits internal sequential state to be shifted in and out.

Controllability: Ease with which a node can be set to a desired value.

Observability: Ease with which a node’s behavior can be seen at an accessible output.

Reliability: Probability of performing a required function for a specified time and condition.

Redundancy: Use of additional resources to detect, mask, or tolerate faults.

Fail-safe: Design behavior that reduces hazard when a fault occurs.

Fault tolerance: Continued required operation despite specified faults.

Secure boot: Process that authenticates software or firmware before execution.

Traceability: Documented linkage among requirements, design, tests, results, and changes.

Review Questions

Short Answer Questions

1. Distinguish verification from validation.
2. What are the principal functions of a digital testbench?
3. Why does high code coverage not necessarily demonstrate functional correctness?
4. Define setup time and hold time.
5. Distinguish a fail-safe system from a fault-tolerant system.

Long Answer Questions

1. Explain how requirements, test cases, assertions, coverage, and traceability work together in a verification process.
2. Discuss functional verification, static timing analysis, and hardware testing as complementary activities.
3. Describe common digital fault models and explain how scan testing improves controllability and observability.
4. Explain reliability, series and parallel architectures, and the limitations of independence assumptions.
5. Discuss the security risks of debug and DFT interfaces and propose lifecycle-aware controls.

Analytical / Application Questions

1. A synchronous path has a maximum clock-to-Q delay of 2 ns, maximum combinational delay of 5 ns, setup time of 1 ns, and total clock uncertainty of 1 ns. Determine the minimum clock period using the simplified setup constraint and calculate the corresponding ideal maximum frequency.
2. Design a verification plan for a four-state safety controller that can enter an error state from any operating state. Identify directed tests, assertions, coverage goals, and at least two fault-injection scenarios.
3. An industrial controller uses redundant sensors but both sensors share the same power supply. Analyze why the apparent reliability improvement may be overstated and recommend architectural or diagnostic measures to address common-cause failure.

Multiple Choice Questions with Answers

Question 1

Which activity primarily determines whether an implementation conforms to its stated requirements?

A. Verification

B. Marketing analysis

C. Product packaging

D. User training

Correct Answer: A. Verification

Question 2

What is the principal role of a scoreboard in a testbench?

A. Generate a clock waveform

B. Compare expected and actual results

C. Synthesize RTL into gates

D. Measure semiconductor temperature

Correct Answer: B. Compare expected and actual results

Question 3

Which statement about functional coverage is correct?

A. It proves that every physical defect is detected

B. It records whether intended behaviors and scenarios were exercised

C. It replaces timing analysis

D. It is identical to statement coverage

Correct Answer: B. It records whether intended behaviors and scenarios were exercised

Question 4

For a simple register-to-register path, which quantity contributes to the setup-time requirement?

A. Maximum combinational path delay

B. Minimum contamination delay only

C. Number of testbench files

D. Package color

Correct Answer: A. Maximum combinational path delay

Question 5

A stuck-at-0 fault models a signal that

A. Changes only during reset

B. Behaves permanently as logic 0

C. Changes twice per clock cycle

D. Has excessive fan-out only

Correct Answer: B. Behaves permanently as logic 0

Question 6

Which DFT method allows internal flip-flop states to be shifted in and out?

A. Scan chain

B. Watchdog timer

C. Parity generator only

D. Clock divider

Correct Answer: A. Scan chain

Question 7

Under the constant-failure-rate exponential model, reliability is represented by

A. R(t) = e^(−λt)

B. R(t) = λt

C. R(t) = t/λ

D. R(t) = λ + t

Correct Answer: A. R(t) = e^(−λt)

Question 8

What is a major limitation of redundancy?

A. It always reduces system complexity

B. It eliminates all common-cause failures

C. It may increase vulnerability to common-cause failures and interactions

D. It prevents fault detection

Correct Answer: C. It may increase vulnerability to common-cause failures and interactions

Question 9

Which measure most directly protects a production device from unauthorized debug access?

A. Increasing screen brightness

B. Disabling or authenticating the debug interface in the production lifecycle state

C. Adding more simulation comments

D. Reducing the number of functional tests

Correct Answer: B. Disabling or authenticating the debug interface in the production lifecycle state

Question 10

Why is configuration control important for verification evidence?

A. It makes all tests execute faster

B. It ensures results can be related to the exact design, tools, and constraints used

C. It removes the need for requirements

D. It guarantees no hardware will ever fail

Correct Answer: B. It ensures results can be related to the exact design, tools, and constraints used