Multiplier Latency Counter

MultiplierLatencyCounter

The sequential module that tracks how many useful multiplication steps have occurred and asserts CountDone when all WIDTH multiplier bits have been processed.

Algorithmic Progress

The role of the latency counter because its count represents completed shift-and-add iterations rather than merely elapsed clock edges.

One Counter Step

Represents one useful multiplication iteration in which one multiplier bit is processed.

WIDTH Useful Steps

The number of shift-and-add iterations required to process all bits of a WIDTH-bit multiplier.

CountDone

The status signal asserted by MultiplierLatencyCounter when the required number of multiplication iterations has been completed.

clear

Control input that reinitializes the latency counter and CountDone for a new multiplication operation.

step

Control input that tells MultiplierLatencyCounter that one useful multiplication iteration is occurring.

localparam COUNTER_WIDTH = $clog2(WIDTH + 1);

Calculates the number of bits required for the internal counter from the parameterized multiplier width.

$clog2(WIDTH + 1)

Returns the number of counter bits needed to represent the required iteration-count range for the parameterized multiplier.

Because the counter width should automatically scale when the multiplier WIDTH parameter changes.

Why is COUNTER_WIDTH calculated from WIDTH instead of being hard-coded?

reg [COUNTER_WIDTH - 1:0] counter;

Stores the sequential progress count of the multiplication operation.

always @(posedge clk)

The clocked procedural block that updates counter and CountDone.

if (reset)

Highest-priority condition that returns MultiplierLatencyCounter to its initial state.

counter <= 0;

Resets the multiplication progress count to zero.

CountDone <= 1'b0;

Clears the multiplication-complete status.

if (clear)

Reinitializes the latency counter for a newly loaded multiplication operation when reset is not active.

Because a new multiplication operation must begin with zero completed iterations regardless of the previous operation's progress.

Why does clear set counter back to zero?

Because the completion status from a previous multiplication must not remain asserted when a new operation begins.

Why does clear set CountDone back to 0?

reset > clear > step

The priority order of operations inside MultiplierLatencyCounter.

if (step && !CountDone)

Allows the progress counter to respond to a multiplication step only while the multiplication has not already been declared complete.

Because the counter should advance only when the datapath actually performs a useful multiplication iteration.

Why is counter not incremented on every clock edge?

Because once completion has been reached, additional step requests must not advance the multiplication progress beyond its terminal condition.

Why is !CountDone included in the step condition?

if (counter == WIDTH - 1)

Detects that the current useful step is the final required multiplication iteration.

WIDTH - 1

The terminal counter value checked before CountDone is asserted.

Because counter begins at 0, so the WIDTH required iterations correspond to count positions 0 through WIDTH - 1.

Why does MultiplierLatencyCounter compare counter against WIDTH - 1 rather than WIDTH?

Count positions 0 through WIDTH - 1

WIDTH distinct iteration positions represented by a zero-based progress counter.

CountDone <= 1'b1;

Marks the multiplication iteration sequence as complete when the final required step occurs.

counter <= counter + 1'b1;

Advances the algorithmic progress count after a non-final useful multiplication step.

CountDone <= 1'b0;

Keeps the completion status deasserted while additional iterations remain.

The counter does not increment in the terminal branch.

Is it true that counter is incremented when counter == WIDTH - 1?

Because reaching counter == WIDTH - 1 while step is asserted already identifies the final required iteration, so completion can be recorded directly without advancing to WIDTH.

Why does the terminal branch assert CountDone instead of incrementing counter again?

CountDone is sticky until reset or clear.

What happens to CountDone after it becomes 1 in MultiplierLatencyCounter?

Because the condition step && !CountDone becomes false after CountDone is asserted, preventing later step activity from modifying the completed state.

Why does CountDone remain asserted after completion?

Latency Counter

A counter whose state represents progress through a multi-cycle operation and provides a completion condition to the controller.

The counter is not merely a timer.

Is MultiplierLatencyCounter simply measuring elapsed time?

Because it advances in response to useful step events rather than indiscriminately counting every clock cycle.

Why is MultiplierLatencyCounter better understood as an algorithmic-progress counter than as a timer?

Controller → step → Latency Counter

The control path by which MultiplierController tells the counter that another multiplication iteration should occur.

Latency Counter → CountDone → Controller

The feedback path by which the counter tells MultiplierController that all required iterations have been processed.

Counter and Controller Close the Loop

The architectural relationship in which the controller commands repeated steps and the counter eventually returns CountDone to terminate RUN.

Datapath and Latency Counter advance together.

What relationship should exist between a useful ShiftAddMultiplier step and a MultiplierLatencyCounter step?

Because otherwise the counter's recorded progress could disagree with the actual number of multiplier bits processed by the datapath.

Why must the latency counter count the same effective steps performed by the multiplier datapath?

Protocol Overhead

The non-arithmetic cycles involved in recognizing the request, loading the datapath, and signaling completion around the useful multiplication iterations.

START-to-DONE Latency

Includes more than the WIDTH arithmetic iterations because the complete external operation also includes control/protocol activity.

Because cycle count includes request recognition, loading, useful iterations, and completion signaling rather than only the counter's arithmetic-progress value.

Why is the externally observed multiplier latency not necessarily equal to the raw counter value?