Functional Decomposition

Functional Decomposition

Dividing a complex digital machine into architectural regions according to responsibility rather than treating the entire design as one undifferentiated block.

Architectural Boundary

A separation between subsystems that defines what responsibility belongs inside each region and what information crosses between regions.

Responsibility

A clearly defined job that one subsystem owns within the complete machine.

Good decomposition separates responsibilities.

What is the central design goal of functional decomposition?

No. Smaller files alone do not guarantee good architecture.

Is functional decomposition merely the act of splitting a large Verilog file into smaller files?

Clear architectural meaning.

What should a module or subsystem boundary provide beyond reducing code size?

Each subsystem should expose only the signals neighboring subsystems need.

What interface principle follows from good functional decomposition?

Local details are hidden behind a smaller, meaningful interface.

What happens to internal implementation details when a subsystem is well decomposed?

Subsystem

A collection of hardware structures cooperating to perform one larger architectural responsibility.

Module vs. Subsystem

A module is an RTL implementation unit, while a subsystem is an architectural responsibility that may contain one or several modules.

One subsystem may contain several Verilog modules.

Can a subsystem consist of more than one module?

Yes. A module can participate as one implementation element within a larger subsystem.

Can one Verilog module be only part of a larger architectural responsibility?

The machine becomes easier to understand, verify, modify, and reason about.

Why is responsibility-based decomposition valuable?

Input subsystem, control subsystem, arithmetic datapath, result-selection subsystem, and physical I/O boundary.

What five major responsibilities organize the Part 09 arithmetic engine?

Input Subsystem

The subsystem responsible for converting uncontrolled physical human actions into trustworthy synchronous command events.

Control Subsystem

The subsystem responsible for remembering selected operation and interpretation mode and expressing execution intent.

Arithmetic Datapath

The subsystem responsible for transforming operands and preserving arithmetic state where required.

Result-Selection Subsystem

The subsystem responsible for choosing and formatting the currently relevant arithmetic result.

Physical I/O Boundary

The architectural boundary that maps board-level switches, pushbuttons, clock, reset, and LEDs to internal machine signals.

Convert physical human actions into safe synchronous events.

What is the primary responsibility of the input subsystem?

Remember selected operation and interpretation mode and emit execution intent.

What is the primary responsibility of the control subsystem?

Transform operands and preserve arithmetic state.

What is the primary responsibility of the arithmetic datapath?

Choose and format the currently relevant result.

What is the primary responsibility of the result-selection subsystem?

Map board-level controls and displays to internal signals.

What is the primary responsibility of the physical I/O boundary?

Physical World → Input Subsystem → Control / Datapath → Result Selection → Physical Output

What high-level decomposition describes the path through the complete arithmetic engine?

Input Conditioning Boundary

The architectural boundary that prevents raw physical button behavior from leaking directly into higher-level control reasoning.

Debouncers and edge detectors.

Which kinds of modules cooperate inside the arithmetic engine's input subsystem?

The input subsystem exports clean command events rather than exposing raw button imperfections to the controller.

What does the input subsystem hide from the control subsystem?

Bounce, timing uncertainty, and persistent physical button levels.

What kinds of physical-interface details should higher-level control not need to reason about?

Clean command pulses.

What should the control subsystem receive instead of raw human button behavior?

The controller should reason about user intent, not button physics.

Why should button conditioning be separated from arithmetic-engine control?

Control Abstraction

The representation of user intention through signals such as Operation, SignedMode, and ExecutePulse rather than raw button behavior.

Operation, SignedMode, and ExecutePulse.

Which signals summarize the control subsystem's high-level interpretation of user intent?

The control subsystem hides navigation details behind compact control-state outputs.

What architectural simplification does ArithmeticEngineControl provide to the rest of the machine?

The arithmetic datapath does not need to know which physical button was pressed to request an operation.

What is one benefit of placing user-interface interpretation outside arithmetic modules?

Interface Hiding

The practice of exposing what neighboring hardware needs while keeping internal implementation details local to the subsystem that owns them.

The adder exposes operands, result, and flags instead of exposing its internal carry-generation structure.

How does an arithmetic module demonstrate interface hiding?

The divider exposes START, BUSY, DONE, ERROR, quotient, and remainder instead of exposing every restoring-division step to topModule.

How does the divider demonstrate subsystem abstraction?

The sequential multiplier exposes transaction-level signals instead of requiring the top level to directly manipulate its internal working registers.

How does the sequential multiplier demonstrate hierarchical decomposition?

Implementation Detail

A lower-level mechanism needed to perform a responsibility but not required for neighboring subsystems to understand that responsibility.

Carry-generation logic.

What is an example of an adder implementation detail that should remain inside the adder subsystem?

Shift-and-add sequencing.

What is an example of multiplier implementation detail that should not be recreated at the top level?

Restoring-division logic.

What is an example of divider implementation detail that belongs inside the divider rather than the top module?

Debounce algorithm.

What physical-interface implementation detail belongs inside the input-conditioning subsystem?

Top-Level Integration

The responsibility of connecting subsystem interfaces and defining how the complete machine behaves externally.

The top level should connect responsibilities rather than reimplement them.

What should topModule primarily do architecturally?

Integration Code

RTL whose primary purpose is to connect modules, distribute signals, decode high-level control, and establish complete-system behavior.

Algorithmic RTL

RTL whose primary purpose is to implement the internal computation or state evolution of a functional unit.

Top-level integration code expresses relationships among subsystems.

What should dominate the architecture of topModule?

The top module should explain how the machine is assembled.

What should a well-designed top-level module make clear to a reader?

It should not re-explain how every arithmetic algorithm works internally.

What should a well-designed top-level module avoid doing?

Flat Design

A design organization in which unrelated responsibilities and implementation details are handled in one large reasoning space.

Hierarchical Design

A design organization in which responsibilities are separated into layers or subsystems with meaningful interfaces.

Button bounce, operation codes, signed interpretation, iterative arithmetic, result widths, and LEDs can become entangled.

What kinds of concerns become mixed together in an overly flat arithmetic-engine design?

Concern Entanglement

The condition in which unrelated responsibilities must be understood simultaneously because architectural boundaries are weak.

Hierarchical decomposition.

What design technique reduces concern entanglement?

A flat design forces interface, control, arithmetic, timing, and output details into the same reasoning space.

Why does a flat design become difficult to reason about?

Each region can be understood largely through its own responsibility and interface.

Why does hierarchical decomposition reduce cognitive load?

Changing one internal implementation may not require redesigning neighboring subsystems if the interface contract remains stable.

How can decomposition improve maintainability?

A subsystem can often be verified independently against its interface behavior.

How can decomposition improve verification?

Local Reasoning

The ability to understand or verify one architectural region without reopening the complete system.

Clear boundaries make local reasoning possible.

Why are architectural boundaries useful during debugging?

When a wrong signal crosses a boundary, the failure can be localized to the producer, consumer, or contract between them.

How can subsystem boundaries help diagnose integration failures?

Interface Contract

The agreed meaning, timing, width, and behavior of signals exchanged between architectural regions.

Subsystems cooperate through interface contracts.

What allows independently designed modules to function as one machine?

A module may be internally correct yet still violate the larger system if its interface behavior does not match neighboring expectations.

Why is module-level correctness not sufficient for system-level correctness?

Because system behavior depends on correct relationships across module boundaries.

Why does Part 09 focus on integration after earlier Parts studied individual modules?

Decomposition

Separating responsibilities into understandable regions.

Integration

Deliberately reconnecting those regions so they cooperate as one machine.

Parts 01–08 emphasized decomposition; Part 09 emphasizes integration.

What major perspective change occurs in Part 09?

Earlier Parts ask how individual architectural ideas work; Part 09 asks how those ideas cooperate.

How does Part 09 differ from the earlier DSD-I Parts?

The arithmetic engine is now treated as a hierarchy of subsystems rather than a list of Verilog files.

What new mental model does Part 09 apply to the project?

System Architecture

The organization of responsibilities, interfaces, control relationships, data paths, timing relationships, and external behavior across the whole machine.

A collection of modules becomes a system only when their interactions are deliberately organized.

Why is instantiating many modules not by itself enough to create good system architecture?

Physical I/O → Input Trust → User Intent → Arithmetic Behavior → Result Selection → Physical Observation

What responsibility chain summarizes the arithmetic engine at the subsystem level?

Physical I/O boundary.

Which subsystem-level responsibility first encounters the board switches and buttons?

Input subsystem.

Which subsystem converts imperfect physical button behavior into commands suitable for synchronous logic?

Control subsystem.

Which subsystem remembers which operation the user selected?

Control subsystem.

Which subsystem remembers whether compatible arithmetic should be interpreted as signed or unsigned?

Arithmetic datapath.

Which subsystem actually contains the hardware that transforms A and B?

Arithmetic datapath.

Which subsystem contains both combinational and stateful arithmetic resources?

Result-selection subsystem.

Which subsystem converts many candidate arithmetic outputs into one outward-facing result representation?

Physical I/O boundary.

Which responsibility finally exposes the selected result through the board LEDs?

The physical interface establishes raw input; the input subsystem makes commands trustworthy; control establishes intent; the datapath performs arithmetic; result selection creates one observable representation.

How do the five major responsibilities cooperate in sequence?

Functional Cohesion

The property that the elements grouped inside a subsystem serve closely related responsibilities.

Input conditioning has high functional cohesion because synchronization, debouncing, and edge-event production all contribute to trustworthy command creation.

Why is the input subsystem a coherent architectural grouping?

Arithmetic units have high functional cohesion within the datapath because they all transform or retain arithmetic information.

Why can many different arithmetic engines still belong to one arithmetic datapath subsystem?

Result packing belongs with result selection because both determine what the outward-facing DisplayValue means.

Why is formatting grouped with selection rather than treated as unrelated logic?

Separation of Concerns

The design principle that unrelated responsibilities should be handled in different architectural regions whenever practical.

Button conditioning and multiplication should be separate concerns.

Give an example of two responsibilities in this project that should not be implemented as one monolithic block.

Operation navigation and divider iteration sequencing should be separate concerns.

Why should the global controller not directly contain every cycle-by-cycle detail of the divider?

Global intent and local algorithmic sequencing operate at different levels of abstraction.

What architectural reason supports separating ArithmeticEngineControl from local iterative controllers?

Abstraction Level

The degree of detail at which a subsystem is described or controlled.

Physical button behavior is a lower-level concern than the abstract command "execute the selected operation."

How does the input pipeline raise the abstraction level of a user action?

START/BUSY/DONE is a higher-level interface than exposing every working register inside a sequential multiplier.

How does a transactional interface raise the abstraction level of an iterative arithmetic unit?

DisplayValue is a higher-level outward interface than exposing separate physical LED groups for every arithmetic unit.

How does result selection simplify the external observation interface?

Subsystem Interface

The limited set of signals through which one subsystem communicates with another.

A good subsystem interface reveals necessary behavior while hiding unnecessary internal detail.

What makes a subsystem interface architecturally useful?

The neighboring subsystem should depend on the contract, not on the producer's internal implementation.

What dependency principle makes subsystem replacement or modification easier?

If the interface behavior remains compatible, internal implementation can often change without forcing changes throughout the system.

Why does encapsulating arithmetic algorithms improve design flexibility?