Branch Taken/Not-Taken Probability

Concept

Branch taken/not-taken probability describes the likelihood that a conditional branch instruction resolves to the taken path versus falling through. In constrained-random verification of microprocessors, this probability is a central concern because naïve random instruction sequences almost never produce the register relationships that satisfy branch conditions, causing forward branches to fall through and backward branches to form effectively infinite loops. Verification engineers therefore impose constraints on the operations preceding branches to raise the taken/not-taken probability to a level that exercises the branch logic without producing degenerate execution patterns.

First seen 6/5/2026

Last seen 6/5/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

In constrained-random verification (CRV) of microprocessors, branch taken/not-taken probability refers to the likelihood that a conditional branch resolves as taken (control transfers to the target) rather than as not-taken (execution falls through to the next sequential instruction). Whether a branch is taken depends on the relationship between the values held in its comparing registers at the moment the branch executes. With pure random stimulus, that relationship is almost never what the branch condition requires, so random instruction streams systematically under-exercise branch evaluation logic.

The Problem with Pure Random Stimulus

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Constraint-Based Branch Stimulus Generation ← uses 94% 1e

Constraint-based branch stimulus controls the probability of branches being taken or not taken.

LINKED ENTITIES

1 links

Constraint-Based Branch Stimulus Generation USES Extracted graph relationship

CITATIONS

6 sources

6 citations — click to expand

[1] Random 32-bit register values are extremely unlikely to satisfy branch conditions, so pure random instruction streams cause forward branches to fall through and backward branches to stall in long loops. Applying Constrained-Random Verification to Microprocessors

[2] Using an ADDI operation of the form R1 = R2 + {-2:2} immediately before a forward branch raises the probability that the branch is taken to roughly 20 percent. Applying Constrained-Random Verification to Microprocessors

[3] The operation preceding a forward branch should be constrained to be an ADDI with the same operands and a small immediate value in order to control the taken/not-taken probability. Applying Constrained-Random Verification to Microprocessors

[4] The operation preceding a backward branch should be an ADDI with the same operands and a small negative value, with the index incremented by 1 inside the loop and the two comparing registers not modified elsewhere in the loop body. Applying Constrained-Random Verification to Microprocessors

[5] Modeling backward branches as loop scenarios avoids absurdly long loops while still producing all conditions from a single fall-through to several loop iterations. Applying Constrained-Random Verification to Microprocessors

[6] Boundary conditions such as a backward BGT branch that is always taken when the comparison register holds the smallest possible value must be considered in the testbench. Applying Constrained-Random Verification to Microprocessors