Multiply Accumulate Unit Part-II

ExtendedUnsignedProduct

The ACC_WIDTH-bit zero-extended representation of Product used when the MAC operates in unsigned mode.

ExtendedSignedProduct

The ACC_WIDTH-bit sign-extended representation of Product used when the MAC operates in signed mode.

wire [ACC_WIDTH - 1:0] ExtendedUnsignedProduct

Declares the accumulator-width version of Product used by the unsigned accumulation path.

wire [ACC_WIDTH - 1:0] ExtendedSignedProduct

Declares the accumulator-width version of Product used by the signed accumulation path.

assign ExtendedUnsignedProduct = {{(ACC_WIDTH - (2 * WIDTH)){1'b0}}, Product};

Zero-extends the 2×WIDTH-bit Product to ACC_WIDTH bits.

ACC_WIDTH - (2 * WIDTH)

The number of additional high-order bits required to widen Product to the accumulator width.

{(ACC_WIDTH - (2 * WIDTH)){1'b0}}

Generates the high-order zeros used to widen Product for unsigned accumulation.

{{(ACC_WIDTH - (2 * WIDTH)){1'b0}}, Product}

The complete zero-extension expression that forms ExtendedUnsignedProduct.

Product occupies the low-order 2×WIDTH bits.

Where is Product placed inside ExtendedUnsignedProduct?

Zeros occupy the newly added high-order bits.

What fills the additional high-order positions of ExtendedUnsignedProduct?

assign ExtendedSignedProduct = {{(ACC_WIDTH - (2 * WIDTH)){Product[(2 * WIDTH) - 1]}}, Product};

Sign-extends the 2×WIDTH-bit Product to ACC_WIDTH bits.

Product[(2 * WIDTH) - 1]

The most significant bit of Product and therefore the bit replicated during signed extension.

{(ACC_WIDTH - (2 * WIDTH)){Product[(2 * WIDTH) - 1]}}

Generates the repeated sign bits placed above Product during sign extension.

{{(ACC_WIDTH - (2 * WIDTH)){Product[(2 * WIDTH) - 1]}}, Product}

The complete sign-extension expression that forms ExtendedSignedProduct.

Because Product[(2 * WIDTH) - 1] is the sign bit of the selected two's-complement product when SignedMode is active.

Why does ExtendedSignedProduct replicate the most significant bit of Product?

Product sign bit = 0

Sign extension inserts zeros into the additional high-order positions.

Product sign bit = 1

Sign extension inserts ones into the additional high-order positions.

ExtendedUnsignedProduct and ExtendedSignedProduct are both ACC_WIDTH bits wide.

What width do the two extended product paths have?

Because the product must have a representation compatible with the ACC_WIDTH-bit Sum before the two values are added.

Why is Product extended before accumulation?

ACC_WIDTH = 2×WIDTH

Under the default parameter relationship, no additional product bits need to be added because product width already equals accumulator width.

ACC_WIDTH > 2×WIDTH

The configuration in which explicit widening adds high-order bits above Product.

The shown extension expressions assume ACC_WIDTH >= 2×WIDTH.

What parameter-width relationship is assumed by ACC_WIDTH - (2 * WIDTH)?

Because ACC_WIDTH - (2 * WIDTH) represents the number of additional high-order bits that must be generated.

Why does the shown extension construction conceptually require ACC_WIDTH to be at least 2×WIDTH?

Product Extension Stage

The MAC datapath stage that converts the selected 2×WIDTH-bit Product into an ACC_WIDTH-bit value while preserving its numeric interpretation.

SignedMode determines both product interpretation and accumulation extension.

What signal coordinates the signed/unsigned interpretation across the multiplication and accumulation portions of the MAC?

SignedMode = 0 → UnsignedProduct → Product → ExtendedUnsignedProduct

The unsigned data path from multiplication through accumulator-width extension.

SignedMode = 1 → SignedProduct → Product → ExtendedSignedProduct

The signed data path from multiplication through accumulator-width extension.

Because choosing signed multiplication but then zero-extending a negative Product would fail to preserve its intended signed value in the wider accumulator datapath.

Why must the extension rule remain consistent with the multiplication interpretation?

output reg [ACC_WIDTH - 1:0] Sum

The persistent ACC_WIDTH-bit arithmetic state that stores the running sum of accepted products.

Sum_current

The accumulated history of products accepted before the current enabled update.

Sum_next

The new accumulated history after the selected extended Product is added.

Sum_next = Sum_current + ExtendedProduct

The general state-update equation implemented by the MAC after product widening.

always @(posedge clk)

Implements the persistent Sum update as synchronous sequential state.

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

Establishes zero as the initial accumulated sum of products.

Because every future MAC result depends on the previous Sum, so the product history requires a known starting state.

Why must the MAC's Sum be initialized by reset?

if (enable)

Determines whether the current A×B product is accepted into the accumulated history on the current rising clock edge.

enable = 0

Sum retains its previous value, so the current product does not become part of the accumulated history.

enable = 1

The appropriately extended current Product is added into Sum on the rising clock edge.

Because a current A×B value should affect arithmetic history only when the surrounding system declares that multiplication event valid for accumulation.

Why does MultiplyAccumulateUnit require enable?

if (SignedMode) Sum <= Sum + ExtendedSignedProduct;

The enabled state update performed when the MAC is operating with signed interpretation.

else Sum <= Sum + ExtendedUnsignedProduct;

The enabled state update performed when the MAC is operating with unsigned interpretation.

Signed enabled update

Sum_next = Sum_current + ExtendedSignedProduct.

Unsigned enabled update

Sum_next = Sum_current + ExtendedUnsignedProduct.

Reset has priority over enable.

What happens if reset and enable are asserted on the same rising clock edge?

Because reset is tested before enable in the sequential always block.

Why does reset override an accumulation request?

Product is combinational; Sum is sequential.

What is the state distinction between Product and Sum in MultiplyAccumulateUnit?

Because Product represents the multiplication of the current operands, while Sum retains the history of products accepted on earlier enabled clock edges.

Why is Product not itself the arithmetic history of the MAC?

Multiplier

Transforms the current A and B operands into Product.

Extension Logic

Preserves the selected Product's numeric meaning while adapting it to ACC_WIDTH.

Adder

Combines the appropriately extended Product with the currently stored Sum.

Sum Register

Stores the updated accumulated total so it can participate in the next MAC operation.

Enable

Determines whether the current product-add operation becomes part of the stored arithmetic history.

Multiplier → extension → adder → Sum register

The main forward datapath of the MultiplyAccumulateUnit.

Sum register → adder

The feedback path that makes the MAC a repeated stateful arithmetic structure.

A, B → multiply → select interpretation → extend → add to current Sum → store next Sum

The complete arithmetic dataflow of an enabled MAC update.

Multiply

The transform stage of the MAC's iterative datapath pattern.

Extend

Preserves the product's numeric interpretation at the accumulator's width.

Combine with Current State

Adds the current extended Product to the previously accumulated Sum.

Store Next State

Captures the newly calculated Sum on the enabled rising clock edge.

Repeat

Allows later operand pairs to contribute additional products to the same persistent Sum.

New data → transform → combine with current state → store next state → repeat

The general iterative-datapath pattern demonstrated by the MAC.

Because the previous Sum is fed back into the next addition instead of being discarded after each product-add operation.

Why is MultiplyAccumulateUnit a stateful datapath rather than merely combinational A×B arithmetic?

Sum of Products

A mathematical expression formed by adding multiple products such as A0B0 + A1B1 + A2B2 + … + AnBn.

Σ AiBi

The compact mathematical notation for the final result of repeated multiply-accumulate operations.

cycle 0: Sum = 0

The initial state of a reset MAC before any products have been accepted.

cycle 1: Sum = A0B0

The accumulated state after accepting the first product from an initial Sum of zero.

cycle 2: Sum = A0B0 + A1B1

The accumulated state after accepting the second product.

cycle 3: Sum = A0B0 + A1B1 + A2B2

The accumulated state after accepting the third product.

Each enabled edge folds one new product into remembered state.

How does a MAC gradually construct a sum of products?

Accepted Product

A product that becomes part of Sum because enable is asserted on the corresponding rising clock edge.

Unaccepted Product

A combinational A×B result that may exist internally but does not alter Sum because enable is inactive.

Because enable determines whether a particular product becomes part of the accumulated arithmetic history.

Why is the distinction between computing a Product and accepting a Product important in a MAC?

MAC = multiplication + memory

The architectural interpretation emphasizing that persistent accumulation, rather than multiplication alone, defines the MAC.

A×B + C alone does not fully capture the defining feature of this MAC.

Is a MAC fundamentally just one isolated calculation of A×B + C?

Because the defining behavior is repeated feedback: the stored Sum becomes the state into which successive products are folded.

Why does Part 05 describe a MAC as multiplication plus memory?

Finite Impulse Response Filtering

One application area in which repeated weighted contributions naturally form sums of products.

Dot Product

A computation that repeatedly multiplies corresponding elements and accumulates their products.

Matrix Multiplication

An important computation whose output elements are constructed from repeated product accumulation.

Convolution

A computation involving repeated multiplication of corresponding terms followed by accumulation.

Control Calculations

Another class of workloads in which weighted contributions may be combined through MAC operations.

Because many algorithms repeatedly compute products and combine those products into a running total.

Why is MAC important enough to be considered a common datapath primitive?

The multiplier and adder form a recurring datapath pair.

Why can specialized MAC-capable hardware be useful?

The accumulator register naturally preserves the running result between cycles.

What stateful hardware property makes MAC particularly suitable for repeated sum-of-products calculations?

Dedicated enable/control determines exactly when a product enters the accumulated history.

What control capability makes a MAC suitable for processing sequences of valid data?

A MAC repeatedly folds new products into remembered state.

What is the central architectural meaning of multiply-accumulate?