Input Subsystems

Input Subsystem

The architectural subsystem that converts uncontrolled physical user actions into clean synchronous command events.

Input Trust Boundary

The boundary between imperfect physical inputs and synchronous logic that expects reliable, well-defined command semantics.

Physical button → Debouncer → ButtonEdgeDetector → one-clock pulse → ArithmeticEngineControl

What complete command path does a normal pushbutton follow in topModule.v?

btnC → NextOperationDebouncer → NextOperationEdgeDetector → NextOperationPulse → ArithmeticEngineControl

What complete path converts the center button into an operation-navigation command?

btnR → SignedModeDebouncer → SignedModeEdgeDetector → SignedModePulse → ArithmeticEngineControl

What complete path converts the right button into a signed-mode command?

btnU → ExecuteDebouncer → ExecuteEdgeDetector → ExecuteButtonPulse → ArithmeticEngineControl

What complete path converts the up button into an execute command?

btnD

Which pushbutton is architecturally different because it serves as reset rather than as an ordinary command?

btnC

Which physical button means "advance to the next arithmetic operation"?

btnR

Which physical button means "toggle signed/unsigned interpretation mode"?

btnU

Which physical button means "execute the currently selected operation"?

btnD

Which physical button returns the machine to a known starting state?

NextOperationDebounced

What clean persistent button-level signal is produced from btnC before edge detection?

SignedModeDebounced

What clean persistent button-level signal is produced from btnR before edge detection?

ExecuteDebounced

What clean persistent button-level signal is produced from btnU before edge detection?

NextOperationPulse

What one-clock architectural command event is produced from the conditioned center-button action?

SignedModePulse

What one-clock architectural command event is produced from the conditioned right-button action?

ExecuteButtonPulse

What one-clock architectural command event is produced from the conditioned up-button action?

The Debouncer stage.

Which stage converts an unreliable physical button level into a stable button level?

The ButtonEdgeDetector stage.

Which stage converts a stable button level into a one-clock command pulse?

A clean persistent level.

What kind of signal exists between each Debouncer and its corresponding ButtonEdgeDetector?

A one-clock synchronous event.

What kind of signal should exist after each ButtonEdgeDetector?

The controller receives events, not raw physical button behavior.

What architectural simplification does the complete input subsystem provide?

Button physics are hidden behind command semantics.

What abstraction does the input subsystem create for ArithmeticEngineControl?

The controller should know that one intentional user action occurred, not how the physical switch behaved electrically.

What information should reach the controller after input conditioning?

It hides physical timing imperfections from the control subsystem.

Why is the input subsystem considered a trust boundary?

The physical world does not naturally obey the clean synchronous timing assumptions of internal digital logic.

Why is a trust boundary needed between buttons and ArithmeticEngineControl?

Physical Event

A real-world user action such as pressing or releasing a pushbutton.

Conditioned Level

A stable synchronous representation of whether a button is logically pressed.

Command Event

A one-clock pulse representing one intentional user action.

Physical Event → Conditioned Level → Command Event

What abstraction progression occurs through the input subsystem?

The signal becomes more abstract and more useful to synchronous control logic.

How does signal meaning change as it moves through the input subsystem?

Raw btnC means a physical voltage level; NextOperationPulse means "advance operation once now."

How does the center-button signal change semantically across the input subsystem?

Raw btnR means a physical voltage level; SignedModePulse means "toggle interpretation mode once now."

How does the right-button signal change semantically across the input subsystem?

Raw btnU means a physical voltage level; ExecuteButtonPulse means "issue one execute request now."

How does the up-button signal change semantically across the input subsystem?

Signal Conditioning

The processing applied to external signals so they satisfy the timing and semantic expectations of internal synchronous logic.

Debouncing and edge detection cooperate to transform a physical button action into a clean synchronous event.

What is the architectural role of signal conditioning in this project?

The controller can operate using clean pulse semantics without implementing physical-input cleanup itself.

Why is signal conditioning separated from ArithmeticEngineControl?

One Intentional Action → One Command Event

The behavioral contract exported by each normal button-conditioning chain.

One press should not be interpreted as several independent navigation or execute requests.

What system-level requirement motivates the input-conditioning chain?

Persistent Button Level

A signal that can remain high for multiple clock cycles while the user continues holding a button.

Command Pulse

A signal intentionally active for only one clock interval to represent an event.

A persistent level represents a condition; a pulse represents an occurrence.

What is the key semantic distinction between a button level and a command pulse?

Because a controller may otherwise respond repeatedly while the button remains pressed.

Why is a command pulse usually more appropriate than a persistent level for "advance once" or "execute once" behavior?

The edge detector converts duration into event semantics.

What architectural transformation does the ButtonEdgeDetector perform?

How long the user keeps the button held.

What physical detail becomes largely irrelevant after edge detection has produced a command pulse?

A one-clock pulse gives the controller a precise synchronous moment at which the command occurred.

Why is event timing easier to reason about after edge detection?

Command Semantics

The meaning assigned to a clean synchronous pulse, such as "next operation," "toggle mode," or "execute."

The same pulse shape can represent different commands because architectural meaning comes from where the pulse is connected.

Why can NextOperationPulse, SignedModePulse, and ExecuteButtonPulse have similar timing but different meanings?

Signal Meaning

A signal's architectural interpretation rather than merely its electrical high/low value.

The subsystem converts electrical button behavior into meaningful control events.

Why is the input path more than just a sequence of wires?

ArithmeticEngineControl.

Which subsystem directly consumes NextOperationPulse, SignedModePulse, and ExecuteButtonPulse?

Global control state.

What kind of subsystem lies immediately downstream of the input subsystem?

Physical input handling should terminate before global user-intent logic begins.

What architectural boundary exists between the edge detectors and ArithmeticEngineControl?

The input subsystem answers "Did a trustworthy user command occur?"

What question does the input subsystem answer?

The control subsystem answers "What should that command change or request?"

What question does ArithmeticEngineControl answer after receiving a command event?

Input conditioning establishes trust; control interprets intent.

What compact distinction separates the input subsystem from the control subsystem?

Debouncer + edge detector.

What two-stage structure appears three times in topModule.v for normal command buttons?

Three Debouncer instances.

How many debouncing blocks are instantiated for btnC, btnR, and btnU?

Three ButtonEdgeDetector instances.

How many edge-detection blocks are instantiated for the three command buttons?

Because each physical command needs its own independent conditioning path.

Why are there separate debouncer and edge-detector instances for btnC, btnR, and btnU?

The chains share structure but preserve different command identities.

What is the architectural significance of using parallel conditioning chains?

Parallel Input Conditioning

Multiple independent physical controls passing through similar cleanup pipelines before entering higher-level control.

btnC, btnR, and btnU can each be converted independently into their own command event.

What benefit does parallel input conditioning provide?

CLOCK_FREQUENCY

Which top-level parameter is passed into each Debouncer to describe the clock environment?

DEBOUNCE_TIME_MS

Which top-level parameter is passed into each Debouncer to define the required stability interval?

The same top-level timing parameters are distributed to all three Debouncer instances.

How is consistent button-conditioning timing achieved across the three command inputs?

Parameter Distribution

The top-level act of supplying shared configuration values to multiple subsystem instances.

The top module configures input-conditioning blocks without reimplementing their internal algorithms.

How does parameter distribution preserve hierarchy?

The top level states the required timing environment; each Debouncer internally implements that responsibility.

What responsibility division exists between topModule and Debouncer regarding timing parameters?

clk

Which common timing signal is supplied to all Debouncer and ButtonEdgeDetector instances?

btnD

Which signal is supplied as reset to all three Debouncers and all three edge detectors?

Common Clocking

The use of one shared clock reference so conditioned events align with the same synchronous timing framework as downstream control.

Because the command pulses must be meaningful relative to the same clock used by ArithmeticEngineControl.

Why should the input subsystem and control subsystem share a common clock?

Synchronous Command

Event information represented in alignment with the system clock so downstream state can respond deterministically.

A clean command pulse is useful because the controller can sample it at a known clock boundary.

Why does synchronization simplify controller behavior?

Interface Normalization

Converting several messy external signals into a common internal signal form expected by downstream logic.

All three ordinary buttons become one-clock pulse-style commands before reaching ArithmeticEngineControl.

How does the input subsystem normalize different user commands?

The controller can use the same fundamental event semantics for navigation, mode toggling, and execution.

What benefit results from normalizing commands into one-clock pulses?

The input subsystem standardizes timing semantics while preserving command meaning.

What two things does input normalization simultaneously accomplish?

Timing Semantics

The rules describing when a signal is considered valid and how long its event representation lasts.

One intentional action becomes one synchronous event.

What timing semantic should the input subsystem guarantee to the controller?

The controller does not need to know whether the physical button remained high for many milliseconds.

What physical timing detail is abstracted away once the command becomes a pulse?

The controller also does not need to know whether the original button signal bounced before stabilization.

What physical instability is intentionally hidden behind the subsystem boundary?

The controller should not inspect raw btnC, btnR, or btnU directly for command decisions.

What design choice preserves the input subsystem's abstraction boundary?

Bypassing conditioning would leak physical-interface behavior into global control logic.

Why would directly connecting raw command buttons to ArithmeticEngineControl weaken the architecture?

Abstraction Leakage

When lower-level implementation or physical details escape a subsystem and force higher-level logic to reason about them.

Having ArithmeticEngineControl directly handle bounce behavior would be abstraction leakage.

Give an example of abstraction leakage at the input/control boundary.

A strong boundary lets the controller treat command pulses as trustworthy facts.

What does the term "trust boundary" mean operationally for downstream logic?

Trustworthy Command

A command signal whose physical-input uncertainty has already been handled enough for downstream synchronous logic to interpret it directly.

The subsystem exports trustworthy command events rather than merely cleaned electrical signals.

What is the real architectural product of the input subsystem?

The product is not "a button"; it is a synchronous event with defined meaning.

What mental shift should you make when looking at NextOperationPulse, SignedModePulse, and ExecuteButtonPulse?

btnD bypasses the normal command-event interpretation and acts as a direct state-management signal.

How is reset routed differently from btnC, btnR, and btnU?

Reset establishes known machine state rather than requesting a normal arithmetic action.

Why is btnD architecturally different from the other three buttons?

State Establishment

The act of forcing stateful hardware into defined values or phases.

Transaction Request

A request asking existing machine state and datapath logic to perform an operation.

Reset establishes state; Execute requests behavior from the established machine.

What is the distinction between reset and execute?

Reset is not simply another item in the command menu.

Why should btnD not be mentally grouped with NextOperationPulse, SignedModePulse, and ExecuteButtonPulse?

Because reset defines the starting conditions from which normal commands can later be interpreted meaningfully.

Why is state establishment logically more fundamental than requesting an arithmetic transaction?

System-Wide Reset Path

A control path distributed broadly to stateful subsystems so they can return to known conditions.

Controller state, accumulators, iterative arithmetic engines, edge detectors, and debouncers.

What categories of stateful hardware receive btnD reset in the integrated architecture?