Combined Test Case

Definition

In functional verification of a design-under-verification (DUV), a combined test case is a single test case that covers several different functions of the design at the same time, rather than testing each function in isolation. The term is used in the context of verification plans that contain multiple tasks targeting different functions, where it is desirable to exercise those functions jointly.

"Test cases that cover different functions are referred to herein as 'combined test cases.'" — US7627843B2 ^[1]

Motivation and Examples

Combined test cases are needed whenever the interactions between distinct functions must be validated together. Two motivating scenarios commonly cited are:

• EXAMPLE 1 — Multi-processor system with I/O. A test case is desired that targets cache operations for the processors while at the same time tests direct memory access (DMA) transactions coming from an I/O device. ^[2]
• EXAMPLE 2 — Single-processor to multi-processor migration. Templates originally built for a single-processor design can be reused and combined with a new template directed at processor enable/disable functions, so the enable/disable behavior is interleaved with all previously verified single-processor functions. ^[2]

A third common requirement is to inject highly specialized configuration-change sequences on-the-fly while other transactions are occurring. ^[2]

Traditional Approaches and Their Drawbacks

Four prior approaches to creating combined test cases are described, each with notable shortcomings:

1. Independent tests combined manually or by post-processing. Test integration is costly and sensitive to environmental changes; events that involve more than one function cannot be represented because the tests are generated independently.
2. Cross-product test templates. Requires a very large template set, limits mixing flexibility, and forces propagation of any function-specific change into many templates.
3. Concatenated combined templates. Concatenation often needs special syntactic effort; scenarios are produced sequentially rather than interleaved, so the generator cannot exploit generation-time proximity to create interesting multi-function events.
4. Mixed stimuli from independent agents. Lacks coordinated stimuli; useless for interleaving transactions originating from a single agent (e.g., one processor performing both cache operations and memory-mapped I/O).

All four approaches suffer from low flexibility and costly maintenance and make it practically impossible to keep up with changes in the design or verification requirements. The drawbacks are amplified when reusing existing templates to verify a follow-on or similar design. ^[3]

Generation by Dynamic Interleaving of Test Templates

To overcome these limitations, combined test cases can be generated by dynamic interleaving of a set of predefined test templates. Each template targets a particular function of the DUV (for example, a template for cache memory accesses specifies that the generator emit a predetermined number of store/load instructions). ^[3]

A typical generation flow:

1. All currently used test templates are read by the test generator.
2. One template is selected as the baseline template (commonly the first encountered) and is given a normalized weight; its transactions are produced exactly one time during generation.
3. Transactions from the remaining templates are interleaved with baseline transactions in a non-predetermined order (often random) according to per-template weights. ^[1], ^[3]

Key Generation Aspects

Several refinements make dynamic interleaving expressive enough for real verification tasks:

• Per-template weights determine the probabilistic ordering of transactions from different templates. ^[1]
• Baseline-template termination: interleaving proceeds until all baseline-template transactions have been generated exactly once, and other templates are generated an integer number of times. ^[1]
• Unbreakable sections: when a template contains an unbreakable section, that template is repeatedly chosen to originate transactions successively until the section completes. ^[1]
• Relative sparseness: a section may specify a transaction sparseness requirement, meaning a predetermined range of transactions from other templates must be interspersed among transactions of the section before it can be completed. ^[1]
• Bounded adjacency: between two occurrences of one template, the number of occurrences of another template can be capped at a predetermined value. ^[1]
• Prologue / epilogue sections: a succession of transactions originating from one template can be emitted before (prologue) or after (epilogue) the interleaved body. ^[1]
• Global testing knowledge: knowledge in the test generator's knowledge base is shared across templates, allowing — for example — two templates to be constrained to access the same randomly selected resource, increasing the quality of generated test cases. ^[2]
• Template arbitration: a template arbitrator unit within the generator engine selects which template contributes the next transaction, independently of the other engine components. ^[2]

Execution

The combined test case produced by interleaving is submitted to an execution engine (a simulator of the DUV or a realization of the design) for execution. ^[2]

Reuse Benefits

Because previously designed templates — already known to be individually reliable — can be recombined in many interleavings, dynamic interleaving supports reuse across designs. In particular, templates authored for a single-processor design can be interleaved with new multi-processor templates to verify enable/disable behavior across all prior functions. ^[1], ^[2]

Relationship to Broader Verification Concepts

Combined test case generation sits inside the larger functional-verification methodology where a verification plan enumerates tasks covering different design functions, and is a building block for multiprocessor verification scenarios in which several processors and I/O subsystems interact. ^[2]

The term "combined test case" is also used, in a different sense, in contemporary software-engineering research on LLM-based autonomous software-development agents, where test-case-based functional assessment is combined with LLM-based requirement verification to evaluate end-to-end development systems. That usage is distinct from the hardware verification meaning defined above. [Public context — arxiv 2511.04064v1]