A quasi-static signal is one that changes only when the logic using it cannot observe the change: during reset, in a quiesced mode, or while the consumer clock is stopped. “Static by construction” means the design enforces that, in hardware or in an unskippable sequence, rather than relying on software discipline.
Mechanism | What makes it provable |
|---|---|
Reset-only configuration | The register's clock or write enable is gated by the reset state; outside reset the value physically cannot change. |
Mode-quiesced updates | A mode state machine enters an idle state, stops the consumers, allows the update, then restarts; the idle state is observable in the design. |
Clock stopped during update | The consumer clock is gated while the new value settles; no edge means no sampling of a changing value. |
One-way mode latches | A bit that software can set but only a reset can clear; monotonicity plus reset gives the proof. |
Quiesce before changing. Drain in-flight transactions and park state machines in idle before touching the value. A configuration changed under a live pipeline is not quasi-static, whatever the register map says.
Change, then settle, then use. Allow the new value to propagate (including across any synchroniser used to deliver it) before the consumers restart.
Make the sequence checkable. The quiesce-acknowledge, the update window, and the restart should be observable signals the review and the assertions can see, not software delays.
One writer. Exactly one agent may change the value in each mode; two writers with “coordinated” timing are a race with documentation.
No. Software restraint is a convention, not a construction: nothing in the design prevents a later write, so a reviewer cannot prove stability. Gate the write with the initialisation state (or reset) to make it structural.