Division Protocol

DividerController

The control FSM that sequences initialization, restoring-division iterations, completion, and divide-by-zero handling.

Divider Controller Responsibility

Organize when the divider datapath loads operands, performs iterative steps, and reports operation status.

The controller does not perform division itself.

What is the most important distinction between DividerController and UnsignedRestoringDivider?

Because UnsignedRestoringDivider performs the arithmetic state transformations while DividerController determines when those transformations are permitted.

Why can DividerController sequence division without containing the restoring arithmetic itself?

Control Supplies Temporal Organization

DividerController determines when each phase of the multi-cycle division process occurs.

Datapath Supplies Arithmetic Transformation

UnsignedRestoringDivider performs the shift, compare/subtract, remainder update, and quotient-bit construction.

START

A request from the surrounding system asking DividerController to begin a division operation.

CountDone

A progress signal informing DividerController that the required restoring-division iterations have been completed.

DivideByZero

An exceptional-condition input telling DividerController that the requested divisor is zero.

load

A controller output commanding the divider datapath to initialize its working registers.

step

A controller output permitting iterative division work during the RUN phase.

BUSY

A status output indicating that the divider is currently engaged in the normal multi-cycle division sequence.

DONE

A status output indicating that the request has reached the controller's completion state.

ERROR

A controller status output indicating a divide-by-zero request while START is being examined in IDLE.

IDLE

The controller state that waits for a new START request.

LOAD

The controller state that initializes the divider datapath for a valid division request.

RUN

The controller state during which restoring-division iterations are requested.

DONE_STATE

The controller state used to signal completion before returning to IDLE.

IDLE → LOAD

A transition taken when START is asserted and DivideByZero is false.

IDLE → DONE_STATE

A special transition taken when START is asserted and DivideByZero is true.

LOAD → RUN

The unconditional transition that follows datapath initialization.

RUN → DONE_STATE

The transition taken when CountDone indicates that the required division progress has completed.

DONE_STATE → IDLE

The unconditional transition that returns the controller to its waiting state.

IDLE + no START → IDLE

Controller behavior while no new division request exists.

IDLE + START + valid divisor → LOAD

The normal beginning of a division transaction.

IDLE + START + zero divisor → DONE_STATE

The exceptional beginning of a divide-by-zero transaction.

Why does a valid START request enter LOAD before RUN?

The divider's working registers must first capture the dividend, divisor, and initial remainder state before iterative steps begin.

Why does LOAD last as a distinct controller phase?

It creates a dedicated initialization event through load before the controller begins asserting step.

Why does LOAD transition unconditionally to RUN?

Once initialization has been requested, the next architectural phase for a valid division is iterative work.

Why does RUN wait for CountDone?

Division requires a known number of iterative quotient-building steps, so the controller must remain in its work phase until progress logic reports completion.

Why does the controller need CountDone if it already has RUN?

RUN says that iterative work is permitted; CountDone says that enough iterations have actually occurred.

CountDone is feedback from progress logic to control.

What architectural relationship does CountDone represent?

step = 1 in RUN

What command does DividerController issue while the divider is in its iterative-work state?

load = 1 in LOAD

What command does DividerController issue while the divider is in its initialization state?

load = 0 outside LOAD

What prevents the datapath from repeatedly reinitializing during normal execution?

step = 0 outside RUN

What prevents restoring-division iterations from occurring during initialization, completion, or idle periods?

BUSY = 1 in LOAD and RUN

During which normal controller states is the divider reported as busy?

BUSY = 0 in IDLE and DONE_STATE

During which states is the controller not reporting active normal division work?

DONE = 1 in DONE_STATE

In which state does DividerController assert completion?

DONE = 0 outside DONE_STATE

What makes DONE a state-specific completion indication rather than a continuously asserted result-valid level?

LOAD: load=1, BUSY=1

The key outputs generated during the divider's initialization phase.

RUN: step=1, BUSY=1

The key outputs generated during the divider's iterative-work phase.

DONE_STATE: DONE=1, BUSY=0

The key outputs generated during the completion phase.

IDLE: BUSY=0

The normal waiting-state status before a valid request begins.

Why is BUSY asserted during LOAD as well as RUN?

Initialization is already part of the active multi-cycle division transaction even though restoring iterations have not started yet.

Why is DONE asserted only after RUN reaches CountDone?

For a normal division request, quotient/remainder construction must finish before the controller advertises completion.

Division Protocol

The temporal contract connecting START, initialization, iterative work, completion, and externally visible status.

START does not mean the result is ready.

What important protocol distinction appears in a multi-cycle divider?

Because START begins a sequence of state transformations whose result becomes meaningful only after the required iterations have completed.

Why can't START and DONE normally represent the same moment?

START → LOAD → RUN… → DONE_STATE

The normal control story for a valid division request.

START + DivideByZero → DONE_STATE

The exceptional controller path that bypasses normal datapath initialization and iterative division.

Why does divide-by-zero bypass LOAD and RUN?

A zero divisor is not a valid normal division operation, so there is no reason to initialize and execute the restoring-division sequence.

Exceptional Control Path

A controller transition that handles an invalid operation differently from the normal arithmetic sequence.

Divide-by-zero is a protocol event as well as an arithmetic condition.

Why does DivideByZero appear as an input to DividerController?

Because detecting an invalid divisor must change the sequence of states the arithmetic engine executes, not merely change an arithmetic value inside the datapath.

Why does divide-by-zero affect control flow?

if (START) begin if (DivideByZero) NextState = DONE_STATE; else NextState = LOAD; end

The IDLE-state next-state logic that separates exceptional requests from valid division requests.

ERROR = 1 in IDLE when START && DivideByZero

The specific condition under which this DividerController implementation asserts its ERROR output.

ControllerError

The ParameterizedDivider wire connected to DividerController's ERROR output.

Controller ERROR Is Combinational in IDLE

In this RTL, the controller's ERROR output depends on the current IDLE state together with START and DivideByZero rather than being retained as controller state.

Why can ControllerError disappear after the controller leaves IDLE?

Its output logic asserts ERROR only for the IDLE condition START && DivideByZero; the FSM then transitions to DONE_STATE where that combinational condition is no longer used to assert ERROR.

Why does ParameterizedDivider later contain ErrorLatched?

The higher-level wrapper needs to retain the divide-by-zero condition beyond the controller's brief IDLE detection event.

ControllerError vs. ErrorLatched

ControllerError is the controller's immediate exceptional-condition indication, while ErrorLatched in ParameterizedDivider preserves the error status for the transaction.

Why is the IDLE → DONE_STATE divide-by-zero transition important even though ERROR is separately generated?

It ensures that an invalid request still follows a completion/status path without entering the ordinary division datapath sequence.

DONE_STATE can represent completion of an invalid request as well as completion of a valid division.

Does reaching DONE_STATE necessarily prove that a normal quotient/remainder calculation occurred?

Because divide-by-zero can transition directly from IDLE to DONE_STATE without executing LOAD or RUN.

Why must DONE and ERROR be interpreted as different kinds of status information?

DONE answers whether the request reached completion; ERROR answers whether the request was invalid.

What conceptual distinction exists between DONE and ERROR?

BUSY answers whether normal multi-cycle processing is currently underway.

What different question does BUSY answer compared with DONE and ERROR?

BUSY, DONE, and ERROR communicate different dimensions of divider status.

Why are three status signals useful rather than treating them as interchangeable?

NextState = CurrentState

The default next-state assignment that causes the FSM to remain in its current state unless later case logic selects a transition.

Why provide a default NextState = CurrentState before the case statement?

It establishes a defined hold behavior for paths that do not explicitly request a transition.

default: NextState = IDLE

The recovery behavior used if CurrentState contains an unrecognized encoding.

CurrentState <= IDLE

The state-register action performed when reset is asserted.

Why does reset return DividerController to IDLE?

IDLE represents the known waiting condition in which no division transaction is being processed.

Controller State Register

The clocked CurrentState register that preserves which protocol phase the divider currently occupies.

Next-State Logic

The combinational logic that uses CurrentState, START, CountDone, and DivideByZero to determine the following controller state.

Output Logic

The combinational logic that converts CurrentState and, in IDLE, exceptional request conditions into load, step, BUSY, DONE, and ERROR.

DividerController uses separate next-state, state-register, and output logic.

What three logical responsibilities can be identified in the controller RTL?

The controller converts a request into timed datapath commands.

What is the central architectural purpose of DividerController?

Surrounding System → START → Controller → load/step → Divider Datapath

The forward command path of the divider's control relationship.

Progress Logic → CountDone → Controller

The feedback path that tells control when iterative work has completed.

DivideByZeroDetector → DivideByZero → Controller

The exceptional-condition path that prevents invalid requests from entering normal division execution.

Controller → BUSY/DONE/ERROR → Surrounding System

The status path by which the divider communicates its transaction condition externally.

Request + arithmetic validity + progress → protocol decisions

What kinds of information does DividerController combine to organize the division transaction?

Because multi-cycle arithmetic separates the moment a request is accepted from the moment its result is complete.

Why does iterative division require an explicit control protocol?