Wide Accumulator

WideAccumulator

A stateful running-sum module whose retained Sum can be wider than each incoming X value.

WideAccumulator vs. Accumulator

WideAccumulator separates input width from accumulator width, whereas the basic Accumulator uses the same WIDTH for both X and Sum.

parameter INPUT_WIDTH = 8

Defines the width of each incoming X value in WideAccumulator.

parameter ACC_WIDTH = 16

Defines the width of the retained Sum and the internal wide arithmetic path.

Because the range needed for accumulated history can be much larger than the range needed for one incoming sample.

Why does WideAccumulator use separate INPUT_WIDTH and ACC_WIDTH parameters?

input wire [INPUT_WIDTH - 1:0] X

Declares X as an INPUT_WIDTH-bit incoming value.

output reg [ACC_WIDTH - 1:0] Sum

Declares Sum as the ACC_WIDTH-bit register that stores the wider accumulated history.

wire [ACC_WIDTH - 1:0] ExtendedX

An ACC_WIDTH-bit internal representation of X used as the accumulator adder's second operand.

Because Sum is ACC_WIDTH bits wide, so X is first converted into a compatible ACC_WIDTH-bit representation before the addition.

Why does WideAccumulator create ExtendedX instead of directly using the narrower X as its intended wide datapath operand?

assign ExtendedX = {{(ACC_WIDTH - INPUT_WIDTH){1'b0}}, X};

Zero-extends the INPUT_WIDTH-bit X into an ACC_WIDTH-bit ExtendedX.

ACC_WIDTH - INPUT_WIDTH

The number of new high-order zero bits inserted above X when constructing ExtendedX.

{(ACC_WIDTH - INPUT_WIDTH){1'b0}}

Generates exactly the number of leading zeros required to widen X from INPUT_WIDTH to ACC_WIDTH.

{{(ACC_WIDTH - INPUT_WIDTH){1'b0}}, X}

Concatenates the generated leading zeros with the original X to create an ACC_WIDTH-bit value.

The original X occupies the low-order INPUT_WIDTH bits.

Where is X placed inside ExtendedX?

Zeros occupy the additional high-order ACC_WIDTH - INPUT_WIDTH bits.

What occupies the newly created upper bits of ExtendedX?

Because the project's WideAccumulator interprets X as an unsigned value.

Why does this implementation zero-extend X rather than sign-extend it?

ExtendedX and Sum are both ACC_WIDTH bits wide.

What width relationship exists between the two operands used by the WideAccumulator's addition?

Sum + ExtendedX

The ACC_WIDTH-wide arithmetic expression used to calculate the next accumulated state.

always @(posedge clk)

Implements WideAccumulator as clocked sequential arithmetic rather than a continuously updating combinational sum.

if (reset) begin Sum <= {ACC_WIDTH{1'b0}}; end

Clears the entire ACC_WIDTH-bit accumulated state to zero.

{ACC_WIDTH{1'b0}}

Produces the correctly parameterized all-zero reset value for the wide Sum register.

Because Sum has ACC_WIDTH bits rather than INPUT_WIDTH bits.

Why does the WideAccumulator reset expression replicate zero ACC_WIDTH times?

if (enable) begin Sum <= Sum + ExtendedX; end

Accepts the current input into the running history on an enabled rising clock edge.

enable = 1

Allows the current ExtendedX value to be added into the retained ACC_WIDTH-bit Sum on the rising clock edge.

enable = 0

Causes the ACC_WIDTH-bit Sum register to retain its existing accumulated state.

Reset → Sum = 0; enabled edge → Sum = Sum + ExtendedX; otherwise → retain Sum

The complete state-update behavior of WideAccumulator.

Reset has priority over enable.

What control priority is implemented by the WideAccumulator?

Because the reset branch is evaluated before the enable branch in the clocked always block.

Why does reset override an asserted enable in WideAccumulator?

ACC_WIDTH-bit feedback

The current wide Sum is fed back as one operand of the next ACC_WIDTH-bit addition.

INPUT_WIDTH-bit input path

X enters the module at its original narrower sample width before being widened into ExtendedX.

ACC_WIDTH-bit arithmetic path

ExtendedX and Sum participate in the addition using the accumulator's wider state width.

Narrow input → width extension → wide addition → wide Sum register

The primary datapath flow through WideAccumulator.

Width extension occurs before accumulation.

At what point in the WideAccumulator datapath is X widened?

Because the value must already have the accumulator's intended width when it participates in the wide Sum + ExtendedX operation.

Why is X extended before it is added into Sum?

ExtendedX is combinational.

Is ExtendedX itself a stored state register?

Because ExtendedX is driven continuously by an assign statement and contains no clocked storage.

Why is ExtendedX combinational rather than state?

Sum is sequential state.

Is Sum merely a combinational result in WideAccumulator?

Because Sum is assigned inside a posedge-triggered always block and retains accumulated history between clock edges.

Why is Sum state while ExtendedX is not?

The wider Sum register, not ExtendedX.

Which signal actually provides the increased storage range of WideAccumulator?

Because extension preserves the current input's value in a wider representation, while the ACC_WIDTH-bit Sum register provides the storage capacity for a larger accumulated history.

Why does zero-extending X alone not create a wide accumulator?

INPUT_WIDTH = 8, ACC_WIDTH = 16

With the project's default parameters, what are the widths of X and Sum respectively?

8 bits

With the default WideAccumulator parameters, how wide is X?

16 bits

With the default WideAccumulator parameters, how wide are ExtendedX and Sum?

8 leading zeros

With INPUT_WIDTH = 8 and ACC_WIDTH = 16, how many zeros are placed above X to form ExtendedX?

{8'b0, X}

Conceptually, what does the default ExtendedX construction become when INPUT_WIDTH = 8 and ACC_WIDTH = 16?

Because changing the parameters automatically changes the declarations, reset width, extension amount, and arithmetic width without rewriting the module.

Why is parameterization particularly useful in WideAccumulator?

ACC_WIDTH must be at least INPUT_WIDTH for this zero-extension expression to make architectural sense.

What width relationship is assumed by the expression ACC_WIDTH - INPUT_WIDTH?

Because ACC_WIDTH - INPUT_WIDTH represents the number of additional high-order bits that must be inserted above X.

Why does the shown implementation conceptually assume ACC_WIDTH >= INPUT_WIDTH?

A wider accumulator delays range exhaustion; it does not eliminate it.

Does using ACC_WIDTH greater than INPUT_WIDTH make WideAccumulator immune to overflow?

Because Sum still contains only ACC_WIDTH bits and therefore still represents a finite numeric range.

Why can WideAccumulator eventually overflow despite having a wider Sum?

The chosen ACC_WIDTH determines how much accumulated numeric history can be retained before the selected fixed-width behavior becomes relevant.

What architectural responsibility remains even after deciding to use WideAccumulator?

Basic Accumulator → same input/state width; WideAccumulator → independently parameterized input/state widths

What is the central RTL evolution from Accumulator to WideAccumulator?

Separate the width of new data from the width of remembered arithmetic history.

What is the central architectural lesson demonstrated by WideAccumulator?