tuGEMM: Area-Power-Efficient Temporal Unary GEMM Architecture for Low-Precision Edge AI

Albert Chen; Anna Li; Harideep Nair; John Paul Shen; Joseph Finn; Manav Trivedi; Prabhu Vellaisamy

REVIEW 3 major objections 5 minor 22 references

tuGEMM: Area-Power-Efficient Temporal Unary GEMM Architecture for Low-Precision Edge AI

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read tuGEMM claims exact GEMM using temporal unary encoding, delivering 8-bit 16x16 compute at 0.05 mm2 and 18 mW, about 15x/11x better area/power than the stochastic uGEMM baseline.

desk verdict A plausible exact temporal-unary GEMM with big PPA claims that hinge on two missing specifications: output accumulator widths and uGEMM baseline conditions. read the letter →

arxiv 2412.17966 v1 pith:DI7TCS3B submitted 2024-12-23 cs.AR cs.AIcs.LG

Harideep Nair , Prabhu Vellaisamy , Albert Chen , Joseph Finn , Anna Li , Manav Trivedi , John Paul Shen This is my paper · ORCID

classification cs.ARcs.AIcs.LG

keywords GEMMunarycomputingtemporalcodinglow-precisionedgeAIexactcomputationarea-powerefficiencyDNNaccelerator

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes tuGEMM, a GEMM architecture that encodes matrix values as temporal pulse widths and performs the multiply-accumulate exactly, unlike stochastic unary systems that compute approximately. Two variants are introduced: a serial design that processes the N outer-product steps one at a time with a counter array, and a parallel design that replicates vector counters and uses adder cells to execute all N steps at once. Post-synthesis results in 45nm CMOS show an 8-bit 16x16 serial design at 0.052 mm2 and 18 mW, and a parallel design at 0.209 mm2 and 53 mW, against a reported uGEMM baseline of 0.770 mm2 and 200 mW. The paper also reports 96.08% MLP accuracy for tuGEMM versus 94.7% for uGEMM, and argues that exact low-precision temporal unary GEMM is attractive for always-on edge AI because average-case latency is much lower than worst case.

What carries the argument

The central mechanism is temporal unary encoding: a value $n$ is represented by a single pulse asserted for $n$ cycles, so multiplication of two values becomes a coincidence of two pulses, and the product magnitude is the number of cycles both pulses overlap. The output array turns those overlaps into signed accumulations: in the serial design each output cell is a counter initialized with $C$ that increments or decrements while both column and row unary signals are asserted; in the parallel design each cell is an adder plus register that combines the $N$ step contributions at once. This encoding avoids random number generators and enables exact arithmetic in the temporal domain.

What would settle it

Re-synthesize both designs in the same 45nm flow with identical clock, bit-widths, and switching activity, and check whether tuGEMM remains roughly 15x/11x smaller in area and power. Also verify that the output counters and adders are wide enough for the full $AB+C$ range on the reported workloads; an overflow or a non-reproducible uGEMM baseline would falsify the exactness and efficiency claims.

Watch

Extended reading notes

Core claim

The central claim is that exact general matrix multiplication can be done in unary hardware by replacing rate-coded stochastic bitstreams with a single contiguous pulse whose duration encodes the value. The architecture computes $Y = AB + C$ by forming the column-row outer products of $A$ and $B$, feeding unary column/row signals into an $M \times P$ array of counter cells (serial) or adder cells (parallel), and accumulating the signed contributions. Because the encoding is deterministic and the final output is read out in binary, the computation is exact rather than approximate, and the low-transition temporal pulse trains cut dynamic power. The reported post-synthesis PPA places serial tuGEMM at roughly 15x lower area and 11x lower power than the uGEMM baseline at 8 bits, with the parallel design at roughly 3.7x/3.8x.

Load-bearing premise

The comparison against uGEMM assumes the published 0.77 mm2 and 0.20 W baseline was measured under equivalent synthesis conditions, bit-widths, and power methodology; if that baseline does not transfer, the headline 15x/11x and 3.7x/3.8x gains are not established.

Editorial extensions

If this is right

If the reported PPA is correct, exact temporal unary GEMM beats the stochastic unary baseline in area and power at 8 bits, and the gap widens at 4 and 2 bits where serial tuGEMM uses as little as 0.011 mm2 and 4 mW.
Because the computation is exact, low-precision tuGEMM avoids the accuracy loss that stochastic approximations add on top of quantization; the paper reports 96.08% versus 94.7% on the uGEMM MLP.
The serial design trades latency for area and power: worst-case latency grows as $N(2^w-1)^2$, but average-case latency on INT8 ResNet18 is about 10x lower because most feature-map maxima are near 41 rather than 128.
The parallel design cuts serial latency by 16x while increasing area and power by only about 5x/4x, which the paper suggests can improve energy efficiency.
Direct cascading is possible because the output is binary, so tuGEMM units can feed other tuGEMM or binary blocks without conversion.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An untested extension is whether the same temporal pulse-width arithmetic applies to other kernels such as convolution or element-wise operations; if the counter and adder cells generalize, the area-power advantage could carry over to full DNN accelerators.
The efficiency story depends on data statistics: an input distribution with many large values would erase the average-case latency benefit, so the architecture is best matched to workloads with sparse or small activations.
A fair comparison would require re-synthesizing uGEMM under the same process, clock, and activity assumptions; until that is done, the exact 15x/11x ratios are provisional.
If counter widths are not explicitly set to cover the full $AB+C$ range, exactness could fail silently on overflow; making those widths explicit and checking them against input ranges would harden the design.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

I largely agree with the reader's conditional verdict. The core idea is genuinely new: an exact temporal-unary GEMM using counter-based accumulation, with serial and parallel variants. The architecture is simple, checkable, and exact by construction if the accumulator widths are adequate. The reported PPA trends—much lower area/power than the stochastic uGEMM baseline, especially at 2 and 4 bits—are directionally credible. The low-precision focus and the ResNet18 latency profiling are also reasonable. Credit is due for a gate-level design and post-synthesis numbers, though the RTL is not released.

The soft spots are real and load-bearing. First, the paper never states the width of the output counters (serial) or adder/registers (parallel). The stress-test note is on target: for 8-bit 16x16, a correct accumulator needs at least 20 bits; if the synthesized designs used narrower accumulators, the exactness claim fails on valid inputs, and the area/power numbers are misleading. This is a missing specification that must be fixed.

Second, the uGEMM comparison is not clearly apples-to-apples. The paper states the uGEMM numbers come from the ISCA paper, but doesn't say whether the same 45nm library, synthesis tool, or activity assumptions were used. Without verifying that, the headline 15x/11x and 3.7x/3.8x gains are not fully established. A third issue is the absence of a conventional binary GEMM baseline, which would help contextualize the latency tradeoff.

The average-case latency claim (10x lower) is rough but not unreasonable: the ResNet18 distribution shows average max magnitude 41 vs 128, and latency scales roughly quadratically, so 10x is plausible. The paper could be more precise, but this is minor.

Overall, this is a solid and honest piece of architecture work. The main concerns are reproducibility and specification gaps, not a flawed concept. I would send it to peer review, but with a strong request that the authors release synthesis artifacts, state all accumulator/adder widths, and add a binary baseline.

Who should read it: hardware architects in unary computing and edge-AI accelerator design. It deserves a serious review, but the current version should be conditional on these clarifications.

Referee Report

3 major / 5 minor

Summary. The paper proposes tuGEMM, a temporal-unary GEMM architecture with serial and parallel variants, and claims exact signed matrix multiplication without the stochastic error of rate-coded unary systems. It reports post-synthesis area and power in 45 nm for 2-, 4-, and 8-bit designs, compares these against the uGEMM baseline, and gives worst-case and average-case latency analyses using INT8 quantized ResNet18. A small MLP accuracy check is also reported.

Significance. If the claims hold, tuGEMM would be a useful alternative to stochastic unary GEMM for low-precision edge AI: exactness by construction, no random number generators, and plausible area-power advantages at low bit widths. The serial/parallel trade-off is clearly articulated, and the PPA trends across bit widths are internally consistent. However, the headline numbers are not yet fully established because output accumulator widths are never specified, the uGEMM comparison lacks methodological normalization, and the average-case latency analysis uses a proxy statistic. The architecture is simple and the central idea is worth publishing after these points are addressed.

major comments (3)

[Section II-B/II-C; Table I] The exactness claim and the reported area/power numbers depend on the width of the output counters and adder registers, which is never stated. For the headline 8-bit 16x16 case, the worst-case per-cell sum magnitude is N*(2^(w-1))^2 + (2^(w-1)-1) = 16*16384 + 127 = 262,271, so a correct signed accumulator needs at least 20 bits; the 32x32 case needs 21 bits. If the synthesized designs use narrower accumulators, valid inputs such as all A and B entries equal to -128 cause overflow and the exact-computation claim fails; if they use full-width accumulators, that choice must be reported because output-counter area and power scale with width and the comparison in Fig. 4 depends on it. This missing specification is load-bearing for both the exactness and the PPA contributions.
[Section III-A] The uGEMM baseline comparison is not established as apples-to-apples. The paper reports only uGEMM's area and power from [21] at 400 MHz; it does not report uGEMM's output accumulator widths, synthesis library/tool versions, or power-estimation activity factors. Since tuGEMM was synthesized with Nangate45 and Synopsys Design Compiler, the 14.8x/11.1x and 3.7x/3.8x gains in Fig. 4 may be inflated by methodology differences. Please provide a normalized comparison under the same library, tool, activity assumptions, and widths, or clearly state the limits of cross-paper PPA comparison.
[Section III-B.2, Fig. 5] The average-case latency claim is based on the maximum value over each intermediate feature map, but tuGEMM's per-step latency is determined by the maximum magnitude of the particular A column and B row entering each step, not by a feature-map-wide maximum. The reported '10x lower' average-case latency therefore does not follow from Fig. 5 without an additional workload model. Please clarify what statistic is plotted and provide a per-GEMM or per-step maximum-magnitude distribution, or rephrase the claim as a conservative upper-bound estimate.

minor comments (5)

[Section II-B] The description of the nested counting behavior is hard to follow: it does not explicitly say when the row counters are reloaded after all rows reach zero. A short timing diagram or pseudocode would make the dataflow unambiguous.
[Section III-B] The accuracy evaluation (96.08% vs 94.7%) lacks experimental setup: the MLP architecture, dataset, quantization method, and how the exact tuGEMM computation was mapped are not described. Please include these details or clearly cite the setup of [21].
[Section III-A] The text reports an average delay reduction of 1.2x/1.1x per 2x bit-width reduction, but Table I contains no delay data. Add a delay table or remove the delay scaling claim.
[Fig. 5] The axis labels and the use of the blue curve versus the cumulative curve are ambiguous; please define the density and CDF axes explicitly and state how the average maximum value of 41 was computed.
[Abstract] The abstract values 0.03 mm^2/9 mW and 0.01 mm^2/4 mW correspond to the serial 16x16 tuGEMM; please state this in the abstract so readers do not compare them with parallel or 32x32 numbers.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: tuGEMM's exactness is structural and the reported PPA and accuracy are measured outputs, not fitted inputs.

full rationale

No circularity found. The paper's central claims are that temporal unary encoding enables exact GEMM by construction and that post-synthesis 45 nm PPA numbers show area/power advantages over uGEMM. The exactness claim is justified by the architecture itself: output counters are initialized with matrix C, each column-row outer product updates them, and "when the index counter asserts output ready, the output counter array holds AB + C." That is a self-contained structural argument, not a restatement of a result the paper is trying to prove. The PPA numbers in Table I are empirical post-synthesis outputs, and the 96.08% accuracy figure is an independent inference check on the same MLP as uGEMM; neither quantity is used as an input or fitted parameter in deriving the design. The only self-citation, [13] (Nair, Shen, and Smith), motivates temporal encoding as an alternative to random bitstreams and is background context, not load-bearing. The uGEMM comparison relies on the externally published uGEMM baseline, which is an ordinary benchmark rather than a circular dependency. The skeptic's concern about unspecified output counter and adder widths is a real missing specification that affects reproducibility and the validity of the exactness and PPA claims, but it is a correctness risk, not a circularity: the paper never defines an output in terms of that omitted width, nor does any reported quantity reduce by construction to an assumed input. Therefore the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on standard hardware assumptions and on the unshown comparability of the uGEMM baseline. No free parameters are fitted to data, and no new physical entities are introduced.

assumptions (4)

domain assumption Nangate45 Open Cell Library with Synopsys Design Compiler provides accurate post-synthesis area and power estimates.
All PPA claims in Table I and Fig. 4 are synthesis outputs, not measured silicon; synthesis accuracy is assumed.
domain assumption uGEMM's published PPA numbers are comparable to tuGEMM's synthesis setup.
Section III-A compares against uGEMM at 400 MHz but does not provide uGEMM RTL, synthesis scripts, or power methodology.
domain assumption Output counter and adder registers have sufficient width to hold AB+C exactly for the reported matrix sizes.
Sections II-B and II-C describe accumulation into counters and registers without stating output bit widths; exactness and area both depend on this.
domain assumption ResNet18 feature-map maximum magnitudes approximate the latency-relevant input distribution of tuGEMM.
Section III-B2 infers a 10x average latency reduction from the distribution of maximum values in feature maps without modeling full GEMM timing.

how reviews work

0 comments

Cite this review

Pith. "Pith review of tuGEMM: Area-Power-Efficient Temporal Unary GEMM Architecture for Low-Precision Edge AI." pith.science (2026). https://pith.science/paper/DI7TCS3B

@misc{pith2026241217966,
  author       = {Pith},
  title        = {Pith review of: tuGEMM: Area-Power-Efficient Temporal Unary GEMM Architecture for Low-Precision Edge AI},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DI7TCS3B}},
  note         = {Machine review of arXiv:2412.17966}
}

read the original abstract

General matrix multiplication (GEMM) is a ubiquitous computing kernel/algorithm for data processing in diverse applications, including artificial intelligence (AI) and deep learning (DL). Recent shift towards edge computing has inspired GEMM architectures based on unary computing, which are predominantly stochastic and rate-coded systems. This paper proposes a novel GEMM architecture based on temporal-coding, called tuGEMM, that performs exact computation. We introduce two variants of tuGEMM, serial and parallel, with distinct area/power-latency trade-offs. Post-synthesis Power-Performance-Area (PPA) in 45 nm CMOS are reported for 2-bit, 4-bit, and 8-bit computations. The designs illustrate significant advantages in area-power efficiency over state-of-the-art stochastic unary systems especially at low precisions, e.g. incurring just 0.03 mm^2 and 9 mW for 4 bits, and 0.01 mm^2 and 4 mW for 2 bits. This makes tuGEMM ideal for power constrained mobile and edge devices performing always-on real-time sensory processing.

Figures

Figures reproduced from arXiv: 2412.17966 by the authors.

**Figure 2.** Parallel tuGEMM architecture for 4x4 GEMM compute [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** A single output adder cell in parallel tuGEMM [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 5.** Figure 5: Percentage of GEMM operations that involve the cor [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 17 canonical work pages

[21]

Ugemm: Unary computing architecture for gemm applications,

D. Wu, J. Li, R. Yin, H. Hsiao, Y . Kim, and J. San Miguel, “Ugemm: Unary computing architecture for gemm applications,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020, pp. 377–390

work page 2020
[1]

Exploiting correlation in stochastic circuit design,

A. Alaghi and J. P. Hayes, “Exploiting correlation in stochastic circuit design,” in 2013 IEEE 31st International Conference on Computer Design (ICCD) . IEEE, 2013, pp. 39–46

work page 2013
[2]

Akida NSoC,

Brainchip Holding Ltd., “Akida NSoC,” https://brainchipinc.com/akida- neural-processor-soc/

work page
[3]

Taking ai to the edge: Google’s tpu now comes in a maker- friendly package,

S. Cass, “Taking ai to the edge: Google’s tpu now comes in a maker- friendly package,” IEEE Spectrum , vol. 56, no. 5, pp. 16–17, 2019

work page 2019
[4]

Nvidia’s xavier soc,

M. Ditty, A. Karandikar, and D. Reed, “Nvidia’s xavier soc,” in Hot chips: a symposium on high performance chips , 2018

work page 2018
[5]

Ai benchmark: Running deep neural networks on android smartphones,

A. Ignatov, R. Timofte, W. Chou, K. Wang, M. Wu, T. Hartley, and L. Van Gool, “Ai benchmark: Running deep neural networks on android smartphones,” in Proceedings of the European Conference on Computer Vision (ECCV) Workshops , 2018

work page 2018
[6]

In-datacenter performance analysis of a tensor processing unit,

N. P. Jouppi, C. Young, N. Patil, D. Patterson, G. Agrawal, R. Bajwa, S. Bates, S. Bhatia, N. Boden, A. Borchers et al. , “In-datacenter performance analysis of a tensor processing unit,” in Proceedings of the 44th annual international symposium on computer architecture , 2017

2017
[7]

Correlation manipulating circuits for stochastic computing,

V . T. Lee, A. Alaghi, and L. Ceze, “Correlation manipulating circuits for stochastic computing,” in 2018 Design, Automation & Test in Europe Conference & Exhibition (DATE) . IEEE, 2018, pp. 1417–1422

work page 2018

Show all 22 references

[8]

Edge ai: On-demand accelerating deep neural network inference via edge computing,

E. Li, L. Zeng, Z. Zhou, and X. Chen, “Edge ai: On-demand accelerating deep neural network inference via edge computing,” IEEE Transactions on Wireless Communications , vol. 19, no. 1, pp. 447–457, 2019

2019
[9]

Energy efficient stochastic computing with sobol sequences,

S. Liu and J. Han, “Energy efficient stochastic computing with sobol sequences,” in Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017 . IEEE, 2017, pp. 650–653

2017
[10]

Systolic tensor array: An efficient structured-sparse gemm accelerator for mobile cnn inference,

Z.-G. Liu, P. N. Whatmough, and M. Mattina, “Systolic tensor array: An efficient structured-sparse gemm accelerator for mobile cnn inference,” IEEE Computer Architecture Letters , vol. 19, no. 1, pp. 34–37, 2020

2020
[11]

Mixed low-precision deep learning inference using dynamic fixed point,

N. Mellempudi, A. Kundu, D. Das, D. Mudigere, and B. Kaul, “Mixed low-precision deep learning inference using dynamic fixed point,” arXiv preprint arXiv:1701.08978, 2017

2017 arXiv
[12]

Convolutional neu- ral networks using logarithmic data representation,

D. Miyashita, E. H. Lee, and B. Murmann, “Convolutional neu- ral networks using logarithmic data representation,” arXiv preprint arXiv:1603.01025, 2016

2016 arXiv
[13]

A microarchitecture implementation framework for online learning with temporal neural networks,

H. Nair, J. P. Shen, and J. E. Smith, “A microarchitecture implementation framework for online learning with temporal neural networks,” in IEEE Computer Society Annual Symposium on VLSI (ISVLSI) , 2021

2021
[14]

CLBlast,

C. Nugteren, “CLBlast,” https://github.com/CNugteren/CLBlast
[15]

Nvidia, “cuBLAS,” https://docs.nvidia.com/cuda/cublas/index.html
[16]

An approximate gemm unit for energy-efficient object detection,

R. Pilipovi ´c, V . Risojevi ´c, J. Bo ˇziˇc, P. Buli ´c, and U. Lotri ˇc, “An approximate gemm unit for energy-efficient object detection,” Sensors, vol. 21, no. 12, p. 4195, 2021

2021
[17]

Edge computing: Vision and challenges,

W. Shi, J. Cao, Q. Zhang, Y . Li, and L. Xu, “Edge computing: Vision and challenges,” IEEE internet of things journal , vol. 3, no. 5, 2016

2016
[18]

Ultra- low precision 4-bit training of deep neural networks,

X. Sun, N. Wang, C.-Y . Chen, J. Ni, A. Agrawal, X. Cui, S. Venkatara- mani, K. El Maghraoui, V . V . Srinivasan, and K. Gopalakrishnan, “Ultra- low precision 4-bit training of deep neural networks,” Advances in Neural Information Processing Systems , vol. 33, pp. 1796–1807, 2020

2020
[19]

The computa- tional limits of deep learning,

N. Thompson, K. Greenewald, K. Lee, and G. Manso, “The computa- tional limits of deep learning,” arXiv preprint arXiv:2007.05558 , 2020

2007 arXiv
[20]

8-bit precision for training deep learning systems,

N. Wang, J. Choi, and K. Gopalakrishnan, “8-bit precision for training deep learning systems,” 2018

2018
[22]

Demystifying tensor cores to optimize half-precision matrix multiply,

D. Yan, W. Wang, and X. Chu, “Demystifying tensor cores to optimize half-precision matrix multiply,” in 2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS) . IEEE, 2020, pp. 634–643

2020

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [21]

Ugemm: Unary computing architecture for gemm applications,

D. Wu, J. Li, R. Yin, H. Hsiao, Y . Kim, and J. San Miguel, “Ugemm: Unary computing architecture for gemm applications,” in 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2020, pp. 377–390

work page 2020

[2] [1]

Exploiting correlation in stochastic circuit design,

A. Alaghi and J. P. Hayes, “Exploiting correlation in stochastic circuit design,” in 2013 IEEE 31st International Conference on Computer Design (ICCD) . IEEE, 2013, pp. 39–46

work page 2013

[3] [2]

Akida NSoC,

Brainchip Holding Ltd., “Akida NSoC,” https://brainchipinc.com/akida- neural-processor-soc/

work page

[4] [3]

Taking ai to the edge: Google’s tpu now comes in a maker- friendly package,

S. Cass, “Taking ai to the edge: Google’s tpu now comes in a maker- friendly package,” IEEE Spectrum , vol. 56, no. 5, pp. 16–17, 2019

work page 2019

[5] [4]

Nvidia’s xavier soc,

M. Ditty, A. Karandikar, and D. Reed, “Nvidia’s xavier soc,” in Hot chips: a symposium on high performance chips , 2018

work page 2018

[6] [5]

Ai benchmark: Running deep neural networks on android smartphones,

A. Ignatov, R. Timofte, W. Chou, K. Wang, M. Wu, T. Hartley, and L. Van Gool, “Ai benchmark: Running deep neural networks on android smartphones,” in Proceedings of the European Conference on Computer Vision (ECCV) Workshops , 2018

work page 2018

[7] [6]

In-datacenter performance analysis of a tensor processing unit,

N. P. Jouppi, C. Young, N. Patil, D. Patterson, G. Agrawal, R. Bajwa, S. Bates, S. Bhatia, N. Boden, A. Borchers et al. , “In-datacenter performance analysis of a tensor processing unit,” in Proceedings of the 44th annual international symposium on computer architecture , 2017

2017

[8] [7]

Correlation manipulating circuits for stochastic computing,

V . T. Lee, A. Alaghi, and L. Ceze, “Correlation manipulating circuits for stochastic computing,” in 2018 Design, Automation & Test in Europe Conference & Exhibition (DATE) . IEEE, 2018, pp. 1417–1422

work page 2018