Memora8 MACC8: INT8 Computation, Memory Bandwidth, and FPGA Timing

AI Summary: During approximately one week of engineering work, we evaluated and implemented the final MACC8 computing configuration for Memora8. It uses two 128-bit operand paths, 16 parallel signed INT8 multiplications, 32-bit accumulation, and four dedicated 8 KiB Block RAM pages. PM1 transfers data between external DDR3 and this bank through a 128-bit interface; the DDR3 MIG native interface remains 256-bit. MACC8 supports two-page multiplication, interleaved single-page operands, squaring, and multiplication by a signed scalar coefficient. It can produce 1–128 independent partial sums per command, written into a dedicated 128 × 32-bit FIFO. At 125 MHz, the arithmetic peak is 2.00 GMAC/s, while on-board measurements including CPU commands and DDR3 transfers reached 0.352 GMAC/s for a fresh 16 KiB A+B pair and 0.628 GMAC/s with reuse of B. Concurrent PM1 transfers and MACC8 calculations increased end-to-end throughput by approximately 16.6% and 28.8%, respectively. The corrected full-system Artix-7 implementation completed routing and bitstream generation with WNS +0.050 ns, WHS +0.022 ns, and no setup, hold, pulse-width, routing, or DRC errors. The new functions and their memory-transfer overlap were verified on the physical FPGA board on November 2, 2026.

Engineering report: implemented RTL, implementation results, and hardware verification as of November 2, 2026.

1. Objective and Scope

Memora8 is a custom 32-bit processor system containing eight CPUs, on-chip SRAM, external DDR3 support, System Bus (SB) devices, and specialized hardware functions. Its memory organization is designed around explicit page transfers and page-level access control rather than unrestricted connections between every processor, memory bank, and hardware function.

MACC8 is the integer multiply-accumulate function device in this system. It accelerates operations where large numbers of small signed integer products must be combined into one or more sums.

The purpose of this development cycle was to identify a configuration that simultaneously satisfied the following constraints:

1. Maintain the existing 125 MHz system clock.
2. Achieve useful INT8 arithmetic throughput without a wider global memory interconnect.
3. Preserve compatible access through the existing Memora8 System Bus.
4. Use the available Artix-7 resources without displacing the other system blocks.
5. Limit the length and fanout of memory-to-arithmetic paths.
6. Permit PM1 to load data while MACC8 operates on different pages.
7. Allow multiple independent accumulated results in one arithmetic pass.
8. Permit CPUs to retrieve results without stopping or restarting MACC8.
9. Complete full-system placement, routing, timing analysis, and bitstream generation.
10. Verify the resulting design on the physical board, not only in simulation.

The study included the feasibility of wider memory transfer paths and alternative arithmetic sizes. The final implementation retains MACC128, meaning 128 bits of data per operand and 16 INT8 multiplications per arithmetic issue. A reduced MACC64 option was discussed but was not selected as the final hardware.

An experimental PM1-256 configuration did not achieve the required timing result. The completed and tested design therefore retains PM1-128, with the 256-bit DDR3 native interface handled separately.

The resulting architecture is a bounded computing subsystem: data is explicitly moved into a small local bank, processed there, and returned as signed 32-bit results through an independent FIFO.

2. Final Implemented Configuration

One MAC denotes one multiplication accumulated into a sum. A 16-element dot-product issue is counted as 16 MACs, not 32 floating-point operations or 16 independent completed commands.

No claim of FP32, FP16, INT16, or arbitrary-precision arithmetic is implied. The implemented computation format is signed INT8, with signed 32-bit accumulation.

3. Memory Architecture and Access Boundaries

3.1. Four-Page Computing Bank

The computing bank contains four pages:

A full page contains 8,192 signed INT8 elements when interpreted as a vector. Viewed as 128-bit operands, one page contains 512 operand blocks.

This bank has a different architectural role from ordinary CPU SRAM. It is a restricted working set for MACC8 and PM1, not a new 32 KiB globally accessible general-purpose memory pool.

MACC8 does not fetch operands directly from DDR3. It executes only on data already present in the computing pages.

3.2. Distinct Roles of PM0, PM1, and PM2

PM0 supports movement between ordinary local memory and the specialized computing bank. This is the available path when software needs to transfer data between CPU-accessible SRAM and MACC8 memory.

PM1 supports transfers between external DDR3 and the four computing pages. In the implemented configuration it cannot address arbitrary general-purpose CPU SRAM pages through its local endpoint.

PM2 is associated with a separate RAW bank. That bank is physically distinct from the MACC8 bank and is not a second wide operand store for the arithmetic device.

These are architectural boundaries, not just software conventions. The corresponding RTL separates the RAW storage from the 128-bit PM1/MACC memory implementation.

3.3. Two Interface Widths at the DDR3 Boundary

The external memory interface and the local PM1 interface have different widths:

The DDR boundary converts between them. Two ordered 128-bit write halves are combined into a 256-bit native write, while a native 256-bit read is returned as two ordered 128-bit responses.

For a full 8 KiB page, the PM1 side transfers 512 units of 16 bytes. The corresponding 256-bit DDR3 data volume is 256 units of 32 bytes, excluding protocol overhead.

The wider native DDR3 interface does not make PM1 a 256-bit local interface. Extending the full 256-bit width into the computing bank would create a different physical design with additional routing and timing consequences.

3.4. Page Ownership

The system maintains ownership at page granularity.

An accepted MACC8 START reserves the page or pages used by that calculation. Conflicting PM transfers are rejected while those pages remain owned.

When the operation completes, the matching reservation is released. Rejected or BUSY START commands do not modify ownership or the result queue.

For a normal two-page A×B operation, two pages are reserved. For A×K and square modes, only A is required and the B field is reserved.

The important property is that reservation of one or two pages does not prevent PM1 from using other free pages in the same computing bank.

3.5. Two-Pair Alternation

The four pages support two working pairs:

• Pair 0: 0x404 and 0x405.
• Pair 1: 0x406 and 0x407.

A steady-state schedule can perform the following operations:

This is double buffering at the page-pair level.

The implementation does not require all four pages to be assigned to one calculation. It also does not claim concurrent reads and writes to the same reserved page.

The actual overlap is established by independent work on disjoint pages, subject to the PM1 and MACC8 command lifecycle.

4. MACC128 Arithmetic Datapath

4.1. Sixteen Signed INT8 Multiplications

For each valid arithmetic issue, MACC8 accepts two 128-bit operands:

A = [a0, a1, ..., a15]
B = [b0, b1, ..., b15]

Each element is interpreted as a signed 8-bit integer in the range −128 to +127.

The issue computes a 16-element dot product:

d = Σ[i=0..15] int8(a[i]) × int8(b[i])

The dot-product result is added to a signed 32-bit accumulator.

For two full pages, there are 512 valid 16-element arithmetic issues, giving:

512 × 16 = 8,192 MAC

At 125 MHz, the theoretical arithmetic issue rate is 125 million dot-product groups per second when the initiation interval is one cycle. Therefore:

16 × 125,000,000 = 2.00 × 10⁹ MAC/s

This 2.00 GMAC/s value is an arithmetic peak, not a measured DDR3 streaming throughput.

4.2. Pipeline Organization

The multiplier lanes and reduction network are pipelined. Intermediate products and partial sums are registered before the final accumulator update.

A local operand register stage was introduced between the memory-selection network and arithmetic logic. The purpose is to break a long combinational path from BRAM output selection to the multiplication and summation network.

For single-page A×B, an additional 128-bit holding register preserves the A operand while the corresponding B operand is read from another address.

The registered control pipeline carries validity, end-of-partial-sum, and final-result indications alongside the data.

The accumulator is reset at the beginning of a command and between partial results as required by the operation. The arithmetic pipeline itself is not drained and restarted between partial sums.

This distinction is significant: producing multiple results does not require repeating the full pipeline-start and pipeline-finish overhead for each result.

The reported configuration retains 16 INT8 products per valid arithmetic issue. The implementation is not a MACC64 core with half the number of lanes.

4.3. Accumulator Width and Exactness

All operand modes use a signed 32-bit accumulator, without saturation.

A full-page calculation performs at most 8,192 signed INT8 multiplications in one result.

The maximum positive product is:

(−128) × (−128) = 16,384

Therefore the maximum possible positive full-page sum is:

8,192 × 16,384 = 134,217,728

This value requires 29 signed bits. It fits within a signed 32-bit result.

The worst negative total is also within the signed 32-bit range. Consequently, the selected accumulation width represents every possible full-page result exactly.

No saturation or loss of higher-order sum bits is required for the implemented workloads.

This statement applies to the specified INT8 operations and maximum 8,192 products per accumulated result. It is not a claim about arbitrary-length accumulations outside the implemented command model.

5. Four Operand Modes

The implemented MACC8 supports four ways of forming operands.

5.1. Two-Page A×B

A and B are selected from any two different pages of the computing bank.

The operation reads corresponding blocks from A and B. Each valid issue contributes 16 products to the current sum.

A full calculation consumes all 8,192 corresponding byte positions.

A and B need not belong to either of the original fixed pairs; the extended command format selects their page indices.

5.2. Single-Page A×B

A and B may also be stored inside one page as alternating sections:

A0 | B0 | A1 | B1 | ... | A(N-1) | B(N-1)

The engine reads a 128-bit A block and retains it locally. It then reads the corresponding 128-bit B block from the same page at a different address.

This mode uses the available memory path without adding another read port solely to achieve one arithmetic issue per cycle.

It consequently performs one valid 16-MAC arithmetic issue every two cycles.

A full page contains both operands, so each vector has half a page of elements:

4,096 MAC

This reduced total is a property of operand storage, not an arithmetic error or a reduction in result precision.

5.3. Square

Square mode computes:

S = Σᵢ aᵢ²

The A data is supplied to both operands of the multiplication network.

It processes all 8,192 elements of the selected page at the normal one-issue-per-cycle rate.

This operation is useful for the sum of squares of signed samples, a squared vector norm, or a signal-energy-related computation when the application uses the corresponding interpretation.

MACC8 does not compute the square root. Any vector-length or RMS calculation requiring further arithmetic must perform those additional steps separately.

5.4. Scalar Coefficient A×K

Coefficient mode multiplies each element of A by one signed 8-bit value:

S = Σᵢ (aᵢ × K)

K has the signed INT8 range:

−128 ≤ K ≤ 127

The coefficient is passed through the System Bus, latched when the START command is accepted, and remains constant for the complete operation.

It is not reloaded for each partial result.

K = 1 produces an ordinary signed sum of the selected input elements. K = 0 produces zero for every completed accumulation.

No second SRAM page is needed to hold repeated copies of the coefficient.

6. Partial Accumulation: 1 to 128 Results

The extended command format supports eight result counts:

N = 1, 2, 4, 8, 16, 32, 64, or 128.

N denotes the number of independently accumulated signed 32-bit results, not the number of pages or the arithmetic lane count.

For two-page A×B, each input page is divided into N corresponding sections. Result j is the sum of products from section j in A and section j in B.

For square or K, the selected page is divided into N consecutive sections.

For single-page A×B, the page is divided into 2N alternating sections:

A0, B0, A1, B1, ... , A(N-1), B(N-1)

Each pair of sections produces one output.

At N = 128:

• the two-page mode accumulates 64 products into each result;
• the single-page mode accumulates 32 products into each result.

All results remain signed 32-bit words regardless of N.

Partial results are emitted in the order of their input sections. Boundaries are carried through the arithmetic pipeline, allowing the accumulator to start a new section without draining the earlier pipeline stages.

The total arithmetic work per full command is unchanged by N within a given operand mode. Increasing N therefore has little effect on the number of arithmetic issues, although it increases the number of results pushed into the FIFO and the subsequent CPU read workload.

7. Dedicated 128-Entry Result FIFO

7.1. Capacity and Purpose

The result device is a dedicated FIFO with:

• 128 entries;
• 32 bits per entry;
• 512 bytes of total payload capacity;
• hardware-only writes from MACC8;
• CPU access through SB group 9, device 5 (0x125).

The queue accommodates the maximum 128 partial results from one command without requiring the CPU to consume a result before the next one is produced.

The FIFO is distinct from the arithmetic accumulator and from the computing SRAM pages.

MACC8 does not write its results back into the operand pages.

The FIFO payload storage is explicitly described in the RTL with a distributed-memory implementation attribute. It is therefore not appropriate to assume that this 512-byte queue necessarily consumes an additional Block RAM primitive.

7.2. FIFO Operations

The implemented commands are:

CPU PUSH and FLUSH operations are not added to this dedicated result interface.

The hardware writes each completed partial sum in order. The CPU can read the queue while another part of the calculation is still in progress.

A POP on an empty queue returns the defined empty/error status rather than an invented data value.

The count representation supports 0 through 128. The implementation accounts for simultaneous hardware PUSH and CPU POP events.

7.3. START Semantics

A successfully accepted new START clears the queue’s head pointer, tail pointer, entry count, and relevant overflow state.

Unconsumed results from the previous operation are discarded logically.

The implementation does not clear all 128 payload words. Logical reset of the queue is sufficient because empty entries cannot be read as valid results.

A rejected START, including one rejected while MACC8 is BUSY, does not clear the queue.

This distinction preserves existing results when software submits an invalid or conflicting command.

7.4. Separate Result-Available and Completion Events

Two different System Bus event sources are used.

The FIFO event is level-sensitive to nonempty occupancy.

The first PUSH activates it. PEEK does not clear it. The final POP clears it if no concurrent PUSH leaves another entry in the queue.

Acknowledging the MACC8 completion event does not consume or discard FIFO contents.

The completion event is published only after the final result has been committed to the FIFO.

These independent events allow software to distinguish between availability of a partial result and completion of the full requested calculation.

7.5. Clock-Domain Interpretation

MACC8 and its result FIFO operate in the same core clock domain.

The word asynchronous in this interface describes the relation between the CPU’s accepted command and the continuing computation.

It does not imply that the result FIFO crosses unrelated clock domains.

No additional clock-domain-crossing FIFO is required between MACC8 and its dedicated result queue.

This should be distinguished from the CDC mechanisms used at the external DDR3 interface.

8. System Bus Interface and Compatibility

8.1. Existing MACC8 Device Address

MACC8 remains at:

SB group 22, device 24 — 0x2D8.

Memora8 uses a 32-word System Bus command window. DATA words provide arguments, and the 32nd word (word 31) initiates the selected device operation.

The baseline control encoding is:

CONTROL = (CMD << 10) | DEVICE
DEVICE  = (GROUP << 5) | DEVICE_NUMBER

For MACC8, DEVICE is 0x2D8.

The extension adds MACC-specific fields to the START control word. It does not redefine the System Bus encoding for unrelated devices.

8.2. Extended START Control Word

The new command retains the standard SB word-31 submission mechanism.

The page indices map directly to 0x404 through 0x407.

For USE_K, the low eight bits of DATA[0] hold the signed coefficient. The upper 24 bits must be zero.

The B selector is reserved as zero for square and K modes, where a second input page is not used.

Simultaneously selecting USE_K and SQUARE is an invalid combination.

The accepted command latches its configuration so that subsequent changes to SB argument storage cannot alter an active computation.

8.3. Legacy START

The older interface is preserved.

Without EXT_START, a fixed-page-pair command can select:

• 0x404 + 0x405; or
• 0x406 + 0x407.

The legacy argument uses DATA[0] equal to 0x404 or 0x406, with DATA[1] equal to zero. This corresponds to one accumulated result over a full two-page operand pair.

The original scalar result-reading behavior remains available for N = 1.

For N greater than one, results are retrieved through the FIFO. The scalar READ command does not silently return only the first partial result; it reports an argument error for unsupported multi-result scalar access.

8.4. Command Lifecycle

The primary MACC commands include START, INFO, STATUS, READ, and ACK.

START returns when the command has been accepted or rejected. It does not block until all 8,192 multiplications have completed.

Software may continue its own execution, use other devices, and retrieve partial results while MACC8 remains active.

A new START while MACC8 is BUSY is rejected rather than automatically queued.

The corresponding response distinguishes invalid arguments, busy conditions, and successful acceptance.

8.5. Final-Cycle Publication Race

Directed verification identified a control race at the boundary where the arithmetic core completed its final accumulation.

Before the correction, READ, STATUS, or ACK could observe an inconsistent combination of core completion and publication state on the final clock transition.

The corrected wrapper treats the operation as active through the publication of the final result and completion event.

As a consequence:

• scalar READ cannot return the previous result at the publication boundary;
• STATUS does not report idle prematurely;
• ACK cannot suppress the newly published completion event;
• the final FIFO write and reported completion remain ordered;
• a new START cannot overlap a still-pending final publication.

The failure was reproduced in a directed test before the change, and the corrected design passed the corresponding test afterward.

The correction was included in the synthesized, routed, and hardware-tested implementation. A simulation-only fix was not substituted for an updated FPGA build.

9. Arithmetic Throughput

9.1. Theoretical Peak

For the normal two-page, square, and scalar-K modes, the initiation interval is one valid 128-bit arithmetic issue per core clock.

At 125 MHz:

16 MAC/cycle × 125,000,000 cycles/s = 2.00 GMAC/s

Single-page A×B requires two alternating memory reads per arithmetic issue.

Its maximum arithmetic throughput is therefore:

(16 / 2) × 125,000,000 = 1.00 GMAC/s

These are peaks of the arithmetic issue process, without including transfer setup, DDR3 loading, command completion, or CPU retrieval of results.

9.2. Pipeline Overhead

A full two-page operation requires 512 valid arithmetic issues. Additional clock cycles occur at command initiation and pipeline completion.

The local core-clock regression records 522 BUSY cycles in the relevant legacy full-page configuration after adding the operand-registration stage. In the surrounding command wrapper, acceptance-to-completion-event publication is approximately 526 cycles.

For illustration:

(8,192 × 125,000,000) / 522 ≈ 1.962 GMAC/s

Using 526 cycles instead gives approximately 1.947 GMAC/s.

Therefore about 1.95–1.96 GMAC/s is an appropriate approximate pipeline-inclusive figure, provided the cycle-count definition is stated.

The values above are derived from the core-clock simulation, not a separate high-resolution measurement of isolated arithmetic execution on the board.

The single-page mode has half the sustained issue rate and an approximate pipeline-inclusive throughput around 0.98 GMAC/s.

These figures must not be presented as measured end-to-end processing rates from DDR3.

9.3. Partial Results Do Not Multiply Arithmetic Work

For a given operand mode, switching N from one to 128 changes the output partitioning but not the number of INT8 products in a full-page pass.

In particular:

N × (8,192 / N) = 8,192

for the full-page modes, and:

N × (4,096 / N) = 4,096

for single-page A×B.

The additional outputs increase FIFO activity and CPU result-reading work. They do not require re-reading the entire operand set for every partial result.

10. On-Board End-to-End Benchmark

10.1. Measurement Objective

A useful arithmetic peak does not establish the sustained rate of a pipeline that receives its data from external memory.

The on-board benchmark therefore measured complete repeated operations containing:

1. PM1 transfer of the required DDR3 data into a free compute page or page pair.
2. MACC8 START and the computation of one full two-page dot product.
3. CPU-side status, synchronization, and result checking.
4. Alternation between the two page pairs.

The benchmark was executed as a program on CPU0.

The timing source was a counter operating at the FPGA’s 125 MHz clock.

UDP was used to prepare the run and retrieve its results, but network transport was excluded from the measured cycle interval.

The benchmark is thus an FPGA-side end-to-end computation-and-transfer measurement, not an Ethernet throughput test.

10.2. Two Data-Reuse Scenarios

Two workload models were tested.

Scenario A: Fresh A and B.

Both operand pages are replaced for each calculation.

Each iteration brings 16 KiB of new operand data from DDR3 and computes 8,192 MACs.

Scenario B: Fresh A, reused B.

A is replaced for each calculation, while B contains a reusable coefficient or weight vector.

Each iteration transfers 8 KiB of new input data and still computes 8,192 MACs against the resident B page.

This is page-level operand reuse. It is not the scalar A×K mode: B remains a full 8 KiB page of signed INT8 elements.

10.3. Serial and Overlapped Schedules

Each workload was executed using two schedules.

Serial schedule: complete the required PM1 loading and then execute MACC8.

Overlapped schedule: execute MACC8 on the current pair while PM1 prepares the next free pair wherever permitted by page ownership.

Both initial page-pair selections were tested: 0x404/0x405 and 0x406/0x407.

Each combination used 1,024 iterations.

There were eight benchmark series in total:

2 workloads × 2 schedules × 2 initial pairs × 1,024 = 8,192 iterations

Results were compared for each calculation. All four computing pages were also verified after each series.

10.4. Measured Results

The following table uses the measurements with initial pair 0x404/0x405. Repeating the same schedules from 0x406/0x407 produced closely matching figures.

Measured values for the second initial pair were:

The measured DDR payload throughput is calculated from the logical number of newly transferred bytes per iteration and the corresponding FPGA cycle count.

It is not a measurement of the maximum DDR3 physical interface bandwidth or the native MIG transfer rate.

Likewise, effective GMAC/s is calculated from 8,192 useful MACs per completed iteration divided by the measured total iteration time.

10.5. Improvement From Overlap

For the fresh A+B workload:

(671.748 / 576.245) − 1 ≈ 16.6%

For the reused-B workload:

(599.097 / 465.017) − 1 ≈ 28.8%

These are improvements in throughput.

The corresponding iteration-time reductions, calculated relative to the serial time, are approximately 14.2% and 22.4%.

The distinction matters because percentage throughput improvement and percentage latency reduction do not use the same denominator.

10.6. Evidence of Actual Concurrent Operation

The overlapped program recorded whether PM1 and MACC8 were simultaneously BUSY.

Every overlapped series recorded the expected concurrent BUSY condition in all 1,024 iterations:

both_busy = 1024/1024, with errors = 0.

This establishes that the measured overlap was not merely a serial transfer followed by a serial computation under a different software label.

It does not mean both devices were BUSY on every clock cycle of each iteration. The sampled condition establishes concurrent activity within the iteration; the measured total time establishes its end-to-end performance effect.

The independently checked computation results and page readbacks establish that the concurrent accesses did not corrupt the tested data.

10.7. Why Measured GMAC/s Is Below Arithmetic Peak

The arithmetic core can execute a complete 8,192-MAC operation far faster than the measured interval required to repeatedly load new operand pages from DDR3.

Even with page-pair overlap, the fresh-data workload achieves approximately 0.352 GMAC/s against a 2.00 GMAC/s arithmetic issue peak.

The arithmetic engine is not issuing products for the entire end-to-end iteration. Much of the time is spent transferring data or coordinating the next operation.

For reused B, halving the incoming operand volume from 16 KiB to 8 KiB significantly improves the effective MAC rate, reaching approximately 0.628 GMAC/s with overlap.

The benchmark therefore demonstrates two different limits:

• the local arithmetic datapath supports a much higher rate once operands are present in SRAM;
• sustained processing of new datasets is substantially constrained by the required transfer and control sequence.

This is why increasing multiplier width alone would not necessarily improve the full-system throughput for these workloads.

10.8. Limits of the Benchmark

The board benchmark covers full two-page A×B with newly loaded operands or reused B.

Square, scalar-K, and single-page A×B modes passed hardware functional tests, but separate DDR3-inclusive performance curves for those modes have not yet been measured.

The benchmark also does not quantify the cost of draining all 128 FIFO entries from software after every operation.

The reported numbers should therefore not be generalized to every partial-result configuration or workload pattern.

11. FPGA Design-Space Decisions

11.1. PM1-256 Was Not the Final Configuration

The possibility of extending PM1 to 256 bits was examined to match the native DDR3 interface width more closely.

However, the tested wider configuration did not deliver the required timing closure.

A nominally wider bus is not sufficient if the implementation creates longer combinational paths, larger selection networks, more routing congestion, or additional placement constraints.

The final design therefore uses PM1-128 while retaining the 256-bit MIG-native interface and converting data at the DDR boundary.

11.2. MACC128 Was Retained

MACC64 was considered as a resource-saving alternative.

It was not incorporated into the final implementation.

The retained MACC128 design keeps 16 parallel INT8 multiplications and the tested arithmetic issue rate.

This report does not claim that an optimized MACC64 would necessarily be slower in every system configuration. No such complete, timing-closed, hardware-benchmarked replacement forms part of the final evidence.

The result is the demonstrated trade-off of this implementation, rather than proof of a globally optimal MACC width for all FPGAs and workloads.

11.3. Local Registration

The arithmetic path includes a local register boundary following operand selection.

This reduces the dependence of multiplier timing on a long combinational connection from the SRAM bank and page multiplexer.

The price is additional latency, not a reduction in the sustained issue rate of the normal modes.

The registered design also requires validity and partial-result boundaries to be aligned correctly with the data. These were included in directed simulation checks.

11.4. Avoiding a Global Computing-Memory Interface

Restricting the engine to four nearby pages limits the scale of the required memory selection network.

This does not eliminate every routing problem, but it makes the arithmetic interconnect more local than a design in which the engine could directly select arbitrary SRAM pages across the full processor cluster.

The architecture deliberately uses explicit PM0 and PM1 transfers to move data into the working set.

12. Synthesis, Placement, and Routed Timing

12.1. Build Environment

The completed implementation targeted the Artix-7 XC7A200T-FBG484-2 and used Vivado 2025.2.

The corrected RTL was synthesized and subsequently implemented through placement, routing, post-route optimization, and bitstream generation.

This distinction matters because a successful RTL simulation or synthesis does not establish that a complete FPGA implementation meets timing.

12.2. Physical Placement Strategy

The successful continuation reused 412 previously validated BRAM/DSP location assignments associated with the PM1-128 baseline.

The preserved constraints placed applicable BRAM and DSP resources at known compatible sites.

LUT and flip-flop placement was left to the implementation tools.

Two previously referenced DSP locations no longer matched the changed accumulation/register mapping, so they were excluded after explicit checking.

This was not a blanket freeze of all placement or an arbitrary assignment of every new arithmetic register.

The implementation retained the existing clock frequencies and timing constraints.

It did not introduce new false paths or multicycle exceptions merely to obtain a positive timing report.

The final successful implementation used the existing synthesis checkpoint for the corrected RTL, followed by normal implementation stages. It did not rely on an uncompleted incremental physical-optimization replay.

12.3. Final Routed Timing

The routed result satisfies the reported setup and hold constraints for this build.

The worst positive setup margin is 50 ps, and the worst positive hold margin is 22 ps. These margins are small in absolute terms.

Positive slack establishes timing closure for the implemented design under the specified constraints. It is not a guarantee that arbitrary subsequent RTL, placement, tool-version, or constraint changes will preserve that result.

12.4. Full-System Resource Utilization

These numbers describe the entire implemented FPGA system, not the MACC8 block in isolation.

The result FIFO did not increase the reported Block RAM count compared with the referenced PM1-128 baseline.

Resource utilization must be interpreted at the correct scope. The 76 DSP blocks, for example, are a system-wide result and must not be presented as the DSP count of the 16-lane MACC engine alone.

An archived PM1-128 baseline report listed 121,216 LUT, 83,699 FF, 302 RAMB36, 42 RAMB18, and 77 DSP. That report provides historical context but is not a newly executed matched A/B synthesis experiment. The differences must therefore not be attributed entirely to the FIFO or partial-result changes.

12.5. Intermediate Reports Versus Final Reports

The corrected synthesis checkpoint initially reported negative preliminary timing estimates. The placed implementation also required further optimization before all timing conditions became positive.

Those intermediate reports are not a failure of the final routed build, nor should they be silently replaced with final numbers when explaining the implementation process.

The completed result is based on the post-route implementation and its saved timing reports.

12.6. Build Duration

The recorded durations of the successful phases were:

The approximately 72-minute figure is the sum of separately executed successful stages, not an elapsed-time measurement of one continuous clean build.

The entire diagnostic session also included a publication-race fix, intermediate implementation work, and an unsuccessful incremental replay attempt. Its recorded span was approximately two hours and four minutes.

The unsuccessful incremental attempt is not evidence that the corrected design failed full placement and routing. Conversely, its incomplete state cannot be counted as a successful implementation.

The final corrected design was routed and the FPGA bitstream was produced successfully.

The measurements do not justify a general guarantee that every future build will complete in less than one hour.

13. Verification Before Hardware Programming

The MACC8 extension was tested through multiple levels before the board checks.

13.1. Arithmetic Reference Tests

The arithmetic verification included 320 independent signed reference cases covering:

• all eight partial-result counts;
• page selections and operand configurations;
• two-page, single-page, square, and coefficient operations;
• positive and negative input data;
• extreme signed K values, including −128 and +127;
• coefficient values −1, 0, and 1;
• result ordering and final-result boundaries.

The reference calculations operated on signed byte data independently of the arithmetic datapath.

The goal was to verify every produced signed 32-bit sum, not merely completion of a command.

13.2. System Bus and FIFO Tests

The surrounding control-device tests covered:

• correct decoding of extended START fields;
• compatibility with the legacy START format;
• invalid argument rejection;
• BUSY rejection;
• atomic page reservation and release;
• FIFO capacity and occupancy;
• FIFO order;
• POP and PEEK;
• reading before overall completion;
• clearing the queue after an accepted new START;
• preserving the queue after rejected START;
• distinct FIFO-available and MACC-completed events;
• ACK behavior;
• the final-result publication boundary.

A directed wrapper test covered 112,230 clock cycles after the final-cycle publication correction.

The final implementation also passed integrated System Bus and cluster-level checks with concurrent PM1 and MACC8 activity.

13.3. Regression of Existing Devices

Regression tests were performed for existing memory and control paths, including DDR burst packing, page transfers, memory pipeline behavior, PM2 reset behavior, System Bus response handling, MMU-related behavior, and selected existing system devices.

Two old test-harness problems were identified and corrected during this process: a mismatched PM0 memory model width and a Verilator-specific hierarchical enum access. Those corrections were distinguished from changes to the actual MACC datapath.

The existing MACC stream behavior and PM1-128 transfer behavior were also rechecked.

14. Hardware Validation on November 2, 2026

14.1. FPGA Programming and Interface Identification

After the corrected bitstream was programmed onto the physical board, the current system interface and device capabilities were inspected.

The test report records the full Memora8 capability identifier 0x00030108, discovery of the dedicated FIFO at 0x125, and successful execution of the new operations.

The bitstream was not read back over JTAG as part of this test. Hardware identification of the new ABI and functional execution provided the operational confirmation of the programmed design.

The tested bitstream was built from the corrected implementation, not the earlier intermediate version containing the publication race.

14.2. Hardware Test Coverage

The board verification produced the following results.

The four CPU programs exercised extended commands, including page selection, a split-page arrangement, square mode, negative K, and multiple partial results.

After the tests, the recorded CPU running mask was zero.

These tests verify the listed logic and memory paths. They do not constitute a blanket claim that every external physical peripheral connected to the board has been tested.

14.3. Uncovered External Peripherals

The hardware verification did not include a full physical test of:

• microSD storage;
• externally connected GPIO and motion hardware;
• camera connections;
• externally connected UART paths.

No SD-card write was performed as part of this MACC8 validation.

The successful MACC8, memory, CPU, and cryptographic tests must not be interpreted as proof of the electrical and operational status of unrelated external devices.

15. UDP Transport Robustness in the Test Client

The same development session restored a host-side UDP retry parameter:

--udp-retry-ms, with a default of 200 ms.

This parameter controls the retransmission interval for the same UDP datagram when the expected response has not arrived.

It is independent of the total request timeout.

The existing polling interval remains a separate concept and is not used as a substitute for the retry period.

Device-reported failures and invalid CRC responses are not silently converted into successful transactions.

Local delay and packet-loss tests were run on macOS and Windows.

A hardware test using a UDP proxy intentionally dropped nine requests or replies, including WRITE/DATA traffic and a COMMIT acknowledgment. The resulting complete 8,192-byte page readback matched the expected data.

This test validates the restored client retry behavior in the tested conditions. It does not change the measured arithmetic or memory bandwidth, since host UDP traffic was excluded from the FPGA benchmark interval.

16. Reproducibility and Evidence Boundaries

The implementation and validation records distinguish several forms of evidence.

The recorded implementation artifacts include synthesis and routed checkpoints, implementation reports, and the generated bitstream.

The build documentation identifies the corrected implementation as the PM1-128/MACC128 FIFO variant, with the final routed checkpoint reporting positive setup and hold slack.

The hardware test records preserve arithmetic-mode logs, page-transfer results, system regressions, and the complete eight-series PM1/MACC benchmark output.

The two principal project reports for this milestone are:

• mr8/docs/MACC8_PARTIAL_FIFO_BUILD_20261102.md — functional development, physical implementation, and build provenance.
• mr8/docs/MACC8_HARDWARE_CHECK_20261102.md — on-board functional validation and benchmark results.

The associated hardware logs are stored in the Memora8 project’s mr8/build/hardware_macc_20261102 test directory.

These names describe development artifacts, not an assertion that every local build file is publicly downloadable.

17. Architectural Interpretation

17.1. Memory Bandwidth Determines Sustained Performance

The 16-lane arithmetic engine has a peak of 2.00 GMAC/s.

The tested full-system throughput is substantially lower when new operand pages must be loaded for each calculation.

For the fresh-pair benchmark, the overlapped sequence reaches approximately 0.352 GMAC/s.

For the reused-B benchmark, it reaches approximately 0.628 GMAC/s.

The second result demonstrates that reducing required external data movement can improve useful compute throughput without changing the arithmetic pipeline or its clock rate.

The relevant optimization target is therefore not just peak multiplications per second. It is the relation between arithmetic work and required data movement.

17.2. Concurrency Has a Measured Benefit

The ability to use one page pair while PM1 fills the other pair is not merely an architectural possibility.

The on-board experiment recorded concurrent BUSY states in every overlapped iteration and measured throughput improvements in both workload types.

The result is particularly relevant because page ownership remains enforced. The overlap does not depend on disabling conflict checks or allowing undefined simultaneous access to the same memory.

17.3. The Result FIFO Separates Producer and Consumer Timing

Without a sufficiently sized result queue, a computation producing many partial sums can become dependent on the CPU reading each result promptly.

The dedicated 128-entry queue holds the maximum result set for the implemented command model.

MACC8 can complete its calculation without blocking on CPU result retrieval.

This makes the computing device an asynchronous producer of ordered result words, rather than a single scalar register that software must continuously service.

The capacity does not eliminate the cost of reading results. It decouples that cost from the progress of the current arithmetic pass.

17.4. Wider Is Not Automatically Better

The PM1-256 attempt illustrates an FPGA-specific implementation constraint.

A wider logical interface can increase data movement per cycle in principle, but also alters placement, fanout, and routing demands.

A configuration that is faster in an ideal functional model is not necessarily useful when the complete design must satisfy timing alongside eight CPUs and other peripherals.

The selected PM1-128/MACC128 configuration is the one for which this engineering cycle has complete implementation and on-board evidence.

17.5. Timing Closure Is a Full-System Property

The final WNS of +0.050 ns and WHS of +0.022 ns belong to the complete FPGA system.

The result depends on the combined CPU, memory, bus, peripheral, clocking, placement, and routing configuration.

It is not sufficient to route the MACC arithmetic module independently and assume that the integrated system will preserve its timing.

The retained BRAM/DSP location constraints, local operand registration, restricted working-set memory, and selected physical optimization sequence all belong to the engineering context of this result.

18. Conclusions

The completed Memora8 MACC8 implementation provides a specialized INT8 computation path with the following confirmed properties:

1. 128-bit operands and 16 parallel INT8 multiplications, operating at a 125 MHz system clock.
2. A dedicated 32 KiB BRAM working bank containing pages 0x404–0x407.
3. A restricted 128-bit PM1 interface connected to external DDR3 through the existing 256-bit native MIG datapath.
4. Independent page ownership, allowing MACC8 to compute while PM1 fills other pages of the same bank.
5. Four operand modes: two-page A×B, single-page interleaved A×B, square, and signed scalar coefficient.
6. Eight partial-accumulation modes, yielding 1–128 exact signed 32-bit results per command.
7. A dedicated 128 × 32-bit result FIFO, with independent result-available and computation-completed events.
8. An asynchronous START interface preserving the prior System Bus device address and legacy command format.
9. Completed routed timing closure with WNS +0.050 ns, WHS +0.022 ns, and no reported timing or routing violations.
10. Completed on-board validation, including arithmetic reference tests, CPU-issued commands, memory transfer regressions, and 8,192 serial/overlapped benchmark iterations.

The principal measured end-to-end results are 0.352 GMAC/s for new A+B data and 0.628 GMAC/s when B is reused, with both cases benefiting from overlap between PM1 transfers and MACC8 execution.

These numbers describe the complete tested data movement and computation cycle. They do not replace the separate 2.00 GMAC/s arithmetic peak specification.

The engineering outcome is a balanced local computing subsystem rather than the widest possible datapath. The experiment demonstrates that sustained performance depends on memory locality, physical routing, independent page transfers, operand reuse, pipeline organization, and software-visible result handling together.

For this implementation and target FPGA, PM1-128 with MACC128 and four-page double buffering is the configuration that passed the complete build and hardware-verification process.

That is the established result of the optimization cycle. It should not be extended into an unsupported claim that the same combination is universally optimal across other FPGA devices, clock frequencies, applications, or memory systems.

Related Memora8 engineering articles: Eight-Core FPGA System Fits Artix-7 200T, Memory Architecture and K4,4 Timing Closure, and Simulator Alignment and Formal CPU Verification.