Parameterized Divider Integration

ParameterizedDivider

The top-level division module that integrates magnitude preparation, unsigned restoring division, control, iteration progress, signed-result reconstruction, and error handling.

Divider Wrapper

A higher-level module that surrounds a core arithmetic datapath with interpretation, control, progress, and interface logic.

Unsigned Magnitude Core

The UnsignedRestoringDivider that performs the actual iterative division using nonnegative operand magnitudes.

Why does ParameterizedDivider use an unsigned restoring core even when SignedMode is supported?

It converts signed operands to magnitudes before division and restores the required signs afterward, allowing one unsigned core to handle the magnitude arithmetic.

SignedMode

Selects whether Dividend and Divisor should be interpreted as signed two's-complement values or ordinary unsigned values.

MagnitudeDividend

The nonnegative magnitude supplied as the Dividend input of UnsignedRestoringDivider.

MagnitudeDivisor

The nonnegative magnitude supplied as the Divisor input of UnsignedRestoringDivider.

MagnitudeQuotient

The unsigned magnitude quotient produced by UnsignedRestoringDivider.

MagnitudeRemainder

The unsigned magnitude remainder produced by UnsignedRestoringDivider.

assign MagnitudeDividend = (SignedMode && Dividend[WIDTH - 1]) ? (~Dividend + 1'b1) : Dividend;

Converts a negative signed Dividend into its two's-complement magnitude while leaving nonnegative or unsigned values unchanged.

assign MagnitudeDivisor = (SignedMode && Divisor[WIDTH - 1]) ? (~Divisor + 1'b1) : Divisor;

Converts a negative signed Divisor into its two's-complement magnitude while leaving nonnegative or unsigned values unchanged.

Dividend[WIDTH - 1]

The sign bit inspected when determining whether a signed Dividend requires magnitude conversion.

Divisor[WIDTH - 1]

The sign bit inspected when determining whether a signed Divisor requires magnitude conversion.

SignedMode && Dividend[WIDTH - 1]

The condition under which Dividend is converted to its magnitude before division.

SignedMode && Divisor[WIDTH - 1]

The condition under which Divisor is converted to its magnitude before division.

~Dividend + 1'b1

The two's-complement operation used by this RTL to obtain the magnitude bit pattern of a negative Dividend.

~Divisor + 1'b1

The two's-complement operation used by this RTL to obtain the magnitude bit pattern of a negative Divisor.

Why is magnitude conversion conditional on SignedMode?

A most-significant bit of 1 indicates negativity only under signed interpretation; in unsigned mode it is simply part of a positive binary value.

SignedMode = 0

MagnitudeDividend equals Dividend and MagnitudeDivisor equals Divisor regardless of their most-significant bits.

SignedMode = 1 with nonnegative operands

The original operand bit patterns pass directly into the magnitude divider.

SignedMode = 1 with negative operand

The operand is converted to its two's-complement magnitude before entering the unsigned divider.

Signed division by magnitude

The strategy of removing operand signs, dividing the nonnegative magnitudes, and then restoring the mathematically required output signs.

Why separate sign interpretation from magnitude division?

It lets UnsignedRestoringDivider focus on one unsigned restoring algorithm while the wrapper handles signed-number meaning.

DivideByZeroDetector ZeroDetector

The instantiated module that determines whether the original Divisor equals zero.

Why can divide-by-zero detection use the original Divisor instead of MagnitudeDivisor?

Zero has the same all-zero bit pattern before and after signed magnitude preparation.

DividerController DividerControl

The instantiated controller that sequences load, step, BUSY, DONE, and divide-by-zero handling.

UnsignedRestoringDivider DividerDatapath

The instantiated arithmetic core that receives MagnitudeDividend and MagnitudeDivisor and produces MagnitudeQuotient and MagnitudeRemainder.

Module Hierarchy

ParameterizedDivider coordinates specialized submodules rather than placing every divider responsibility into one monolithic block.

ZeroDetector → validity

What responsibility does DivideByZeroDetector contribute to ParameterizedDivider?

DividerControl → temporal sequencing

What responsibility does DividerController contribute to ParameterizedDivider?

DividerDatapath → magnitude arithmetic

What responsibility does UnsignedRestoringDivider contribute to ParameterizedDivider?

Wrapper logic → interpretation and integration

What responsibility does ParameterizedDivider itself add around the specialized submodules?

localparam COUNTER_WIDTH = $clog2(WIDTH + 1)

Computes the number of counter bits allocated for tracking the required WIDTH division iterations.

counter

A progress register that tracks how many restoring-division steps have occurred.

CountDone

A registered completion indication supplied to DividerController when the required number of steps has been reached.

EffectiveStep

The gated step signal that permits a datapath iteration only while the controller requests step and CountDone is not already asserted.

assign EffectiveStep = step & ~CountDone;

Prevents an additional restoring-division datapath update after iteration completion has been detected.

Why does ParameterizedDivider distinguish step from EffectiveStep?

step expresses the controller's RUN-state request, while EffectiveStep suppresses further datapath work once CountDone has been reached.

step = 1 and CountDone = 0 → EffectiveStep = 1

The condition that permits an actual restoring-division iteration.

CountDone = 1 → EffectiveStep = 0

The condition that blocks another datapath iteration even if the controller still currently asserts step.

Why is EffectiveStep important at the completion boundary?

The controller and progress logic update on clock edges, so gating step prevents the datapath from accepting an unwanted extra iteration while completion propagates through control.

load → counter = 0 and CountDone = 0

The progress-state initialization performed when a new valid division is loaded.

EffectiveStep → update progress

The event that advances the divider's iteration tracking.

counter == WIDTH - 1

The condition used during an EffectiveStep to recognize the final required division iteration.

Why compare counter with WIDTH - 1?

The counter begins at zero, so the WIDTHth permitted iteration corresponds to the pre-update count value WIDTH - 1.

CountDone <= 1'b1

The progress indication generated when the final required EffectiveStep occurs.

counter <= counter + 1'b1

The progress update performed when another iteration remains after the current one.

Why is counter not incremented in the counter == WIDTH - 1 branch?

The final required iteration has already been recognized, so completion is signaled instead of advancing to another iteration count.

CountDone <= 0 when no EffectiveStep

This implementation makes CountDone a short-lived progress indication rather than a permanently retained completion flag.

Why does the controller need CountDone only as a progress event?

Its purpose is to trigger the RUN-to-DONE_STATE transition once the required restoring iterations have finished.

WIDTH restoring steps

The number of iterative quotient-bit decisions required by this WIDTH-bit divider.

Why are WIDTH iterations required?

The restoring divider constructs a WIDTH-bit quotient one quotient decision at a time.

NegativeQuotient

A register that remembers whether the final signed Quotient must be negative.

NegativeRemainder

A register that remembers whether the final signed Remainder must be negative.

Why must output-sign information be stored?

The divider operates across multiple cycles, so the signs associated with the accepted request must survive while magnitude division is occurring.

if (load) NegativeQuotient <= SignedMode && (Dividend[WIDTH - 1] ^ Divisor[WIDTH - 1]);

Captures whether the final signed quotient should be negative when the division operands are loaded.

Dividend sign XOR Divisor sign

The sign rule used to determine whether a signed quotient is negative.

Same operand signs → nonnegative quotient

What quotient sign results when Dividend and Divisor have matching signs?

Different operand signs → negative quotient

What quotient sign results when Dividend and Divisor have opposite signs?

Why does XOR implement the quotient sign rule?

XOR is 1 exactly when the two operand sign bits differ.

if (load) NegativeRemainder <= SignedMode && Dividend[WIDTH - 1];

Captures whether the final signed remainder should be negative.

Dividend sign

The sign rule used by this RTL for the signed remainder.

Why does NegativeRemainder depend on Dividend rather than Divisor?

The implementation gives the remainder the same sign as the Dividend.

Why are NegativeQuotient and NegativeRemainder captured on load instead of continuously recomputed?

They must describe the operands accepted for the active multi-cycle transaction even if the external input signals later change.

Transaction Context

State retained by a multi-cycle unit so later output interpretation still corresponds to the request that originally started the operation.

SignedMode is part of the transaction's interpretation context.

Why is it unsafe to rely only on live external signedness information after a multi-cycle operation has begun?

Because result reconstruction must correspond to the signed interpretation of the request whose magnitudes were actually loaded and processed.

MagnitudeQuotient → optional two's-complement negation → Quotient

The final signed quotient reconstruction path.

MagnitudeRemainder → optional two's-complement negation → Remainder

The final signed remainder reconstruction path.

NegativeQuotient ? (~MagnitudeQuotient + 1'b1) : MagnitudeQuotient

The normal final-output expression that restores the quotient sign.

NegativeRemainder ? (~MagnitudeRemainder + 1'b1) : MagnitudeRemainder

The normal final-output expression that restores the remainder sign.

Why is two's-complement negation applied after magnitude division?

The unsigned core produces nonnegative magnitude results, so the wrapper must reconstruct the requested signed representation afterward.

Signed positive quotient

MagnitudeQuotient passes directly to Quotient when NegativeQuotient is false.

Signed negative quotient

The two's complement of MagnitudeQuotient is driven onto Quotient when NegativeQuotient is true.

Signed nonnegative remainder

MagnitudeRemainder passes directly to Remainder when NegativeRemainder is false.

Signed negative remainder

The two's complement of MagnitudeRemainder is driven onto Remainder when NegativeRemainder is true.

(-Dividend magnitude) / (+Divisor magnitude) → negative Quotient

What quotient-sign behavior results from operands with opposite signs?

(+Dividend magnitude) / (-Divisor magnitude) → negative Quotient

What quotient-sign behavior results from a positive Dividend and negative Divisor?

(-Dividend magnitude) / (-Divisor magnitude) → nonnegative Quotient

What quotient-sign behavior results when both signed operands are negative?

Negative Dividend → negative Remainder

What remainder-sign behavior is implemented for a negative signed Dividend?

Positive Dividend → nonnegative Remainder

What remainder-sign behavior is implemented for a nonnegative signed Dividend?

ErrorLatched

A transaction-status register that remembers whether START occurred with DivideByZero asserted.

if (START) ErrorLatched <= DivideByZero

The error-capture rule used by ParameterizedDivider.

Why is ErrorLatched captured on START while sign flags are captured on load?

A divide-by-zero request never reaches LOAD, so its exceptional status must be captured when START is observed; sign flags are needed only for a valid request that proceeds into LOAD.

ErrorLatched ? {WIDTH{1'b0}} : normal Quotient reconstruction

The highest-priority output selection rule for Quotient.

ErrorLatched ? {WIDTH{1'b0}} : normal Remainder reconstruction

The highest-priority output selection rule for Remainder.

Why does ErrorLatched have priority over sign reconstruction?

A divide-by-zero request has no valid normal quotient/remainder result, so exceptional output handling overrides ordinary signed-result formation.

assign ERROR = ErrorLatched

Exposes the remembered exceptional status at the ParameterizedDivider interface.

Valid unsigned transaction

Operands pass unchanged into the unsigned core and magnitude results pass unchanged to the normal outputs.

Valid signed transaction

Negative operands are converted to magnitudes, unsigned magnitude division executes, and stored sign information reconstructs the signed outputs.

Invalid divide-by-zero transaction

Normal iterative division is bypassed, ErrorLatched records the failure, outputs are forced to zero, and ERROR indicates invalidity.

Signed Divider Dataflow

Interpret signs → form magnitudes → perform unsigned magnitude division → restore quotient/remainder signs.

Divider Control Flow

Check validity → load working state → perform EffectiveSteps → detect completion → report DONE.

Divider Error Flow

Detect zero divisor → bypass normal division → retain error status → suppress normal result interpretation.

Why can the unsigned core remain simpler than the complete ParameterizedDivider?

Sign handling, protocol, progress, and exceptional conditions are intentionally placed around it rather than embedded into its restoring arithmetic.

Core Arithmetic vs. Interpretation

The magnitude divider determines numerical magnitudes, while wrapper logic determines how operand and result bit patterns should be interpreted as signed or unsigned.

Core Arithmetic vs. Protocol

The magnitude divider performs one arithmetic step when commanded, while controller/progress logic determines when those commands occur.

Core Arithmetic vs. Exceptional Handling

The magnitude divider assumes valid magnitude operands, while surrounding logic detects and communicates invalid requests.

Magnitude preparation occurs before the iterative core.

Where is signedness removed from the operands in the ParameterizedDivider architecture?

Sign restoration occurs after the iterative core.

Where is signedness reintroduced into the final Quotient and Remainder?