Assertions and Interfaces Preview

An assertion states a rule that must hold every cycle. Once written, the simulator checks it automatically — no directed test required for that specific rule. A simple protocol assertion against the capstone's own signals looks like this:

// Protocol rule: outside reset, start and done must never both be high on the same clock edge.
assert property (@(posedge clk) disable iff (rst) !(start && done));

If a bug ever causes start and done to go high together outside reset, the simulator reports the violation on the exact cycle it happens — instead of a wrong result surfacing several cycles later with no direct link back to the cause. disable iff (rst) just tells the checker not to evaluate the rule while rst is asserted, since a design's signals are not expected to follow their normal protocol during reset.

An interface bundles related signals — like a small bus — so they connect and travel together as one named group instead of many separate wires listed individually in every port list. Take the capstone's own tiny_calc_top: clk, rst, load_en, load_addr, load_data, start, op_sel, done, and result each appear separately in every module port list that needs them today. An interface would bundle all nine into one named group that a module connects to at once. Both constructs exist for the same reason: as a design grows past a handful of signals, checking behavior and wiring modules together by hand stops scaling. Course 2 teaches both in depth.