An interface bundles the signals of a bus into one named, instantiable object. That single idea fixes three chronic problems at once: port-list sprawl (a wide bus becomes one port), connection errors (signals travelling together cannot be cross-wired), and testbench races (clocking blocks give every component the same race-free view).
The lessons build in order: bundle the signals, restrict direction with modports, add clocking blocks for timing discipline, then parameterize the bundle and embed bus-functional tasks. Classes reach all of it through a virtual interface: a class-side handle whose value is set at runtime to point at one real, elaborated interface instance. That handle now lives in the virtual interfaces topic.
Construct | What it contributes |
|---|---|
A signal bundle | One port instead of N; cross-wiring disappears at the language level. |
A | A named direction view per role; wrong-direction drives fail at compile time. |
A clocking block | Pre-edge sampling plus skewed driving, shared by every testbench component. |
Parameters plus tasks | One reusable bundle that also knows its own pin choreography. |
Lesson | Path | It covers |
|---|---|---|
Required | Declaring the bundle, sharing one instance, and named versus generic ports. | |
Recommended | Mirror-image DUT and testbench views and the limits of what they check. | |
Required | Skewed sampling and driving, cycle counting, and the one-path rule. | |
Recommended | A parameterized bundle with automatic read and write tasks. |
Path: Required is the core first pass for this part's goal, a self-checking testbench; Recommended is what most learners should read; Optional is reference, specialist or revision material to return to later.
bus_if and connect one side each. What happens?Both compile and nothing communicates. Each instance is a separate copy of the nets. Only modules holding the same instance share signals.