Pith. sign in

REVIEW 3 major objections 4 minor 26 references

Optimizing Scalable Multi-Cluster Architectures for Next-Generation Wireless Sensing and Communication

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read For wireless manycores, cluster granularity, not just core count, decides performance: a 256-core cluster can be twice as fast as 16 16-core clusters, and a soft barrier adds more.

desk verdict Useful empirical cluster-granularity study with a neat soft barrier, but the 2x memory-bound result leans on a constant-L2-bandwidth assumption and unmatched matmul sizes; treat as a design guideline, not a settled optimum. read the letter →

arxiv 2507.05012 v1 pith:L6RKHQSU submitted 2025-07-07 cs.AR

Samuel Riedel , Yichao Zhang , Marco Bertuletti , Luca Benini This is my paper · ORCID
classification cs.AR
keywords manycoreRISC-Vsynchronizationshared-memoryclustersclustergranularityjointcommunicationandsensingdoublebufferingbarrier
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

Next-generation wireless processing (6G, joint communication and sensing) demands hundreds of programmable cores, and the standard design template groups them into shared-memory clusters that are then scaled out. This paper asks how large each cluster should be when the total core count and total memory are fixed. It extends the open-source MemPool shared-memory cluster into multi-cluster configurations (2x128, 4x64, 8x32, 16x16) and compares a single 256-core cluster against them on wireless sensing and communication kernels. The central finding is that cluster granularity is a first-order performance variable: the single large cluster is up to 2x faster on memory-bound kernels (axpy, dotp) and up to 24% faster on compute-bound kernels (2dconv, dct, matmul), because fewer clusters reduce synchronization, drift, and DMA-communication overhead. A proposed soft barrier that decouples the core barrier from the DMA barrier adds another 5-9% on compute-bound kernels while slightly hurting memory-bound kernels in this system.

What carries the argument

The central objects are the MemPool cluster and the soft barrier. MemPool is an open-source RISC-V shared-memory cluster with up to 256 cores sharing a 1 MiB L1 scratchpad; the paper extends it to multi-cluster configurations that hold the total core count and L2 bandwidth constant while splitting the L1 across clusters. The soft double-buffering barrier is the named mechanism: instead of a hard barrier that makes every core and the DMA wait for the whole system to finish a phase, it lets each actor proceed when its own next buffer is ready, with the last core to finish resetting the barrier and programming the next DMA transfer. This decoupling lets the paper attribute performance differences to synchronization and data-movement overhead rather than to memory capacity or bandwidth.

What would settle it

Simulate or build the 16x16 configuration with per-cluster-scaled L2 bandwidth and run axpy and dotp; if the 16-cluster system matches or beats the single 256-core cluster, the central claim's constant-bandwidth assumption is falsified.

Watch

Extended reading notes

Core claim

On its own terms, this paper establishes that cluster granularity, not just total core count, is a first-order design variable for shared-memory manycores running wireless sensing and communication workloads. With a fixed budget of 256 cores, 1 MiB of L1 memory, and a constant L2 bandwidth, consolidating cores into fewer larger clusters cuts the synchronization, inter-cluster drift, and DMA-transfer overhead that dominate many-small-cluster systems. Memory-bound kernels (axpy, dotp) prefer a single 256-core cluster, up to 2x faster than 16 16-core clusters, because large clusters use L2 bandwidth through larger, latency-tolerant DMA transfers; compute-bound kernels (2dconv, dct, matmul) also favor larger clusters, with gains up to 24%, though the largest cluster loses a few percent to NUMA stalls and the paper identifies 128 cores per cluster as the sweet spot for this class. The paper additionally proposes a soft double-buffering barrier that separates the DMA barrier from the core barrier, letting cores start the next compute phase as soon as their buffer is ready; this recovers 5-9% on compute-bound kernels while slightly degrading memory-bound kernels in this implementation.

Load-bearing premise

The comparison assumes every configuration connects to the same constant-bandwidth L2 memory through the same system interconnect, so a physically scaled multi-cluster design that pays for extra interconnect or suffers L2 contention could see the large-cluster advantage shrink or reverse.

Editorial extensions

If this is right

  • For a fixed 256-core budget, replacing 16 16-core clusters with a single 256-core cluster can double the throughput of memory-bound kernels (axpy, dotp) and cut compute-bound kernel time by up to 24%.
  • Compute-bound kernels (matmul, 2dconv, dct) have a sweet spot near 128 cores per cluster; memory-bound kernels prefer 256 cores per cluster, so the optimal granularity depends on kernel arithmetic intensity.
  • The soft barrier's decoupling of DMA and core synchronization is a low-cost technique that recovers 5-9% on compute-bound kernels and should be applicable to other double-buffered manycore systems.
  • Most of the gain comes from consolidating many small clusters into fewer medium ones; moving from 8x32 to 1x256 gives diminishing returns and the largest cluster can lose performance on 2dconv and matmul due to NUMA stalls.
  • With process scaling and physically viable 1024-core clusters, the optimal cluster size may rise into the thousands, since the limiting costs are interconnect area, latency, and bandwidth rather than a fixed architectural bound.

Reading between the lines

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

  • If the constant-bandwidth L2 assumption is relaxed to model a physically scaled multi-cluster chip, the 1x256 vs 16x16 gap should shrink; a bandwidth-scaled simulation would quantify how much of the 2x memory-bound speedup is architectural versus assumed in the setup.
  • The paper lists GPU streaming-multiprocessor sizes oscillating from 32 to 192 cores without explaining the choices; its 128-256 core sweet spot offers a candidate rationale for the recent 128-core SM sizing in Ampere and Ada.
  • The soft-barrier scheme should generalize to any decoupled producer-consumer pipeline, including systems with separate input and output DMA channels, where memory-bound kernels could gain overlap the way compute-bound kernels do here; the paper mentions but does not evaluate that case.
  • The matmul benchmark tiles matrix size down to fit each cluster's L1 (192x192 to 48x48), which changes arithmetic intensity and partly confounds the compute-bound comparison; holding matrix size fixed while tiling in software would isolate the cluster-size effect.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper studies cluster granularity in shared-memory manycore processors for joint communication and sensing (JCAS) workloads. It extends the open-source MemPool architecture into a multi-cluster system with equal total core count (256) and equal total L1 capacity, while keeping a single constant-bandwidth L2/system interconnect. It introduces a 'soft' double-buffering barrier that decouples core and DMA synchronization. Using cycle-accurate RTL simulations of five double-buffered kernels (dct, matmul, axpy, 2dconv, dotp), it compares configurations from 16x16 up to 1x256. The central empirical claim is that a single large cluster can be up to 2x faster than 16 small clusters for memory-bound kernels and up to 24% faster for compute-bound kernels, with optimal cluster sizes around 128 cores for compute-bound and 256 cores for memory-bound kernels. The paper also argues that soft barriers give 5-9% speedups on compute-bound kernels by overlapping compute phases across clusters.

Significance. If the results hold, the paper makes cluster granularity a first-order design variable for JCAS manycores and provides a simple, low-cost synchronization primitive (the soft barrier) with measured benefits on compute-bound kernels. The evaluation is transparent for an architecture paper: cycle-accurate RTL simulations, deterministic core/DMA timelines, a constant total core and L1 budget, and no fitted parameters. The platform is open source, and the authors' prior TeraPool-SDR work gives the 1024-core scaling discussion some grounding. The main caveats are that the results are simulation-based and depend on a constant-bandwidth L2 model, and the matmul comparison changes problem sizes across configurations, which confounds the compute-bound comparison.

major comments (3)
  1. [Section III (Architecture), Fig. 1] The constant-bandwidth L2 model is load-bearing for the memory-bound speedups. The text states that 'the system interconnect links all clusters to a constant-bandwidth L2 memory,' and Fig. 1 labels both systems with the same L2 bandwidth. Under this model, one 256-core cluster can aggregate DMA traffic into large, latency-tolerant bursts, and the reported 2x and 1.7x gains for axpy and dotp follow directly. A physically scaled 16-cluster design would, however, be expected to have per-cluster DMA engines and, in many designs, per-cluster L2 slices or a richer interconnect, so aggregate L2 bandwidth would not be constant across configurations. If constant bandwidth is the intended equal-resource baseline, that should be stated and defended; otherwise, please add a sensitivity study or a variant where bandwidth scales with cluster count, and show whether the memory-bound ranking is robust.
  2. [Section V (Evaluation Setup), matmul paragraph] The matmul comparison is confounded by changing problem sizes: MemPool 1x256 operates on 192x192 matrices, while 16x16 operates on 48x48 matrices with four iterations, and the text admits that the tiling affects arithmetic intensity. The compute-bound results in Fig. 6 cannot therefore be attributed to cluster granularity alone, because the 16x16 configuration is simultaneously more fragmented and operating at a different arithmetic intensity with four DMA phases. Please re-run matmul with the same logical matrix and the same per-iteration tile size across all configurations, or at least report arithmetic-intensity-normalized results and separate the tiling effect from the cluster-size effect.
  3. [Section VII (Cluster Scaling Limits)] The section's headline 'compute-bound kernels perform best at 128 cores per cluster' is not strongly supported by the data shown. Fig. 6 and Section VI-A report that MemPool 4x64, 2x128, and 1x256 perform within 4-7% for compute-bound kernels, with 1x256 sometimes slightly worse. Given that the gains are small and the configurations are few, I recommend presenting per-kernel absolute numbers and a clear definition of the optimum (mean, median, or per-kernel best) before making the 128-core recommendation load-bearing in the conclusion.
minor comments (4)
  1. [Section VI-A (Timelines)] The text reports 'up to 89% gains' for memory-bound kernels with hard barriers and later 'speedup of 2x and 1.7x' for axpy and dotp; please reconcile these percentages (89% is 1.89x) and state the reference configuration consistently.
  2. [Figure 4] The timeline figure is too dense to read in the typeset version; the per-cluster compute/DMA bars should be enlarged, split across panels, or accompanied by a zoomed-in steady-phase inset.
  3. [Section IV-A (Soft Barriers)] The soft-barrier description uses 'first core' and 'last core' roles; please specify how these roles are determined when multiple cores arrive at the barrier simultaneously, since the atomic counter only identifies the last core.
  4. [Section VI-B.3 (Breakdown)] The sentence 'the fastest cores become partly memory-bound while slower ones remain compute-bound' in 2dconv is unclear; a short example or a per-core activity plot would help.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the evaluation is an empirical RTL simulation comparison with no fitted parameters, and the self-citations to MemPool and TeraPool-SDR provide independent, externally realized baseline platforms.

full rationale

The paper's contribution is an empirical evaluation of cluster granularity: it extends the open-source MemPool cluster into a multi-cluster system and measures cycle-accurate RTL simulations of JCAS kernels under hard and soft barriers. There are no fitted parameters, no derived quantities that are defined in terms of the quantities they are said to predict, and no equation in the paper reduces the headline speedup to an input assumption. The main self-citations are [7] (TeraPool-SDR, a 1024-core shared-L1 cluster) and [8] (MemPool), which are prior silicon/open-source artifacts rather than theorems or fitted models; they are used as the physical platform and as evidence that clusters of several hundred cores are feasible, and they remain externally falsifiable outside this paper's results. The claim that "the system interconnect links all clusters to a constant-bandwidth L2 memory" (Section III) is a modeling assumption, not a circular definition: the measured 2x memory-bound speedup does not follow by construction from that assumption, since the same aggregate L2 bandwidth is provided to every configuration and the observed differences come from DMA transfer granularity, barrier drift, and synchronization behavior measured in simulation. The varying matmul matrix sizes (192x192 down to 48x48) do change arithmetic intensity and confound the compute-bound comparison, but this is a benchmark-design limitation, not a circular derivation. The soft double-buffering barrier is an implementation contribution evaluated by comparison, and no uniqueness claim is imported from the authors' prior work to force the design choice. Overall, the central claim rests on simulation evidence with stated architectural assumptions, so no circular step is present.

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

No numerical model is fitted to data. The central dependency is the choice of matmul matrix sizes and the assumption of a constant L2 bandwidth across all configurations. The paper also relies on simulation fidelity and representativeness of the chosen JCAS kernels.

free parameters (1)
  • matmul matrix dimension per configuration = 192, 128, 96, 64, 48 (configs 1x256, 2x128, 4x64, 8x32, 16x16)
    Chosen so that six matrix buffers fit into the per-cluster L1 memory; this changes arithmetic intensity and iteration count (192 vs 48 inner iterations), which confounds the compute-bound comparison.
assumptions (4)
  • domain assumption Cycle-accurate RTL simulation faithfully models the timing of the real MemPool design.
    All performance and drift numbers are extracted from RTL traces; no silicon or FPGA measurements are presented to confirm that the simulator timings match physical hardware.
  • domain assumption All cluster configurations are served by the same constant-bandwidth L2 memory and system interconnect.
    Section III and Fig. 1 assume a constant L2 bandwidth regardless of cluster count; a physical scale-out could add interconnect or contention and change the comparison.
  • domain assumption The five selected kernels represent the relevant JCAS workload mix.
    Section V justifies kernels through an OTFS proposal and AI-enhanced sensing, but coverage of the full 6G use-case space is not demonstrated, so generalization is assumed.
  • ad hoc to paper Matmul matrices of different sizes are comparable as versions of the same kernel.
    Section V changes matrix size from 192x192 to 48x48 to fit L1, changing arithmetic intensity and iteration count; treating these as one kernel across configurations is a paper-specific assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Optimizing Scalable Multi-Cluster Architectures for Next-Generation Wireless Sensing and Communication." pith.science (2026). https://pith.science/paper/L6RKHQSU

@misc{pith2026250705012,
  author       = {Pith},
  title        = {Pith review of: Optimizing Scalable Multi-Cluster Architectures for Next-Generation Wireless Sensing and Communication},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L6RKHQSU}},
  note         = {Machine review of arXiv:2507.05012}
}
read the original abstract

Next-generation wireless technologies (for immersive-massive communication, joint communication and sensing) demand highly parallel architectures for massive data processing. A common architectural template scales up by grouping tens to hundreds of cores into shared-memory clusters, which are then scaled out as multi-cluster manycore systems. This hierarchical design, used in GPUs and accelerators, requires a balancing act between fewer large clusters and more smaller clusters, affecting design complexity, synchronization, communication efficiency, and programmability. While all multi-cluster architectures must balance these trade-offs, there is limited insight into optimal cluster sizes. This paper analyzes various cluster configurations, focusing on synchronization, data movement overhead, and programmability for typical wireless sensing and communication workloads. We extend the open-source shared-memory cluster MemPool into a multi-cluster architecture and propose a novel double-buffering barrier that decouples processor and DMA. Our results show a single 256-core cluster can be twice as fast as 16 16-core clusters for memory-bound kernels and up to 24% faster for compute-bound kernels due to reduced synchronization and communication overheads.

Figures

Figures reproduced from arXiv: 2507.05012 by the authors.

Figure 1
Figure 1. Architecture of MemPool (or MemPool1×256) (left) and the multi-cluster extension illustrated on MemPool16×16 (right). Both systems have the same L2 bandwidth and access to a global interrupt controller with dedicated lines to all clusters. the system interconnect links all clusters to a constant-bandwidth L2 memory (on-chip SRAM or off-chip DRAM). Clusters synchronize using atomic memory operations (AMOs) on private… view at source ↗
Figure 2
Figure 2. Timeline of double-buffered executions for compute [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. DCT-based waveform generation for OTFS JCAS. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Timeline of the kernels with hard barriers (left) and soft barriers (right) on different multi-cluster configurations. The blue lines represent the clusters’ active compute phases. The yellow and green lines represent the clusters’ DMA activity. barrier configurations,…
Figure 5
Figure 5. Figure 5: Relative performance of different barrier implementations [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: Relative performance comparison of different MemPool [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: Breakdown of cores’ activity with hard (top) and soft barriers (bottom). The first two bars show time spent on compute (e.g., additions, multiplications) and control (e.g., loads, branches) instructions. Remaining bars capture idle phases: synchronization (barrier slee…
Figure 8
Figure 8. Figure 8: The time drift of each kernel with soft barriers is shown relative to the total pipeline execution time. The y-axis is linear up to 5%, then logarithmic to show all nuances. show no drift, as a single DMA phase dictates phase end. For dotp, the final phase shows signif…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages

  1. [1]

    Recommendation ITU-R M.2160: Framework and overall objectives of the future development of IMT for 2030 and beyond,

    ITU, “Recommendation ITU-R M.2160: Framework and overall objectives of the future development of IMT for 2030 and beyond,” https://www.itu.int/ rec/R-REC-M .2160-0-202311-I/en, 2023

    work page 2023

  2. [2]

    Joint design of communication and sensing for beyond 5G and 6G systems,

    T. Wild, V . Braun, and H. Viswanathan, “Joint design of communication and sensing for beyond 5G and 6G systems,” https://www .nokia.com/bell- labs/research/6g-networks/6g-technologies/network-as-a-sensor/, 2023

    work page 2023

  3. [3]

    Integrated sensing and communications: Toward dual- functional wireless networks for 6g and beyond,

    F. Liu et al. , “Integrated sensing and communications: Toward dual- functional wireless networks for 6g and beyond,” IEEE Journal on Selected Areas in Communications , vol. 40, no. 6, pp. 1728–1767, 2022

    work page 2022

  4. [4]

    NVIDIA Ampere GA102 GPU architecture,

    NVIDIA Corporation, “NVIDIA Ampere GA102 GPU architecture,” https: //www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture- whitepaper-v2.pdf, NVIDIA Corp., Tech. Rep., 2020

    work page 2020

  5. [5]

    Nvidia aerial gpu hosted ai-on-5g,

    A. Kelkar and C. Dick, “Nvidia aerial gpu hosted ai-on-5g,” in 2021 IEEE 4th 5G World Forum (5GWF) , 2021, pp. 64–69

    work page 2021

  6. [6]

    A qualitative approach to many-core architecture,

    B. Dupont de Dinechin, “A qualitative approach to many-core architecture,” in dupo, L. Andrade and F. Rousseau, Eds. Hoboken, New Jersey, USA: Wiley, Apr. 2021, ch. 2, pp. 27–51

    work page 2021

  7. [7]

    TeraPool-SDR: An 1.89TOPS 1024 RV-cores 4MiB shared-L1 cluster for next-generation open-source software-defined radios,

    Y . Zhang, M. Bertuletti, S. Riedel, M. Cavalcante, A. Vanelli-Coralli, and L. Benini, “TeraPool-SDR: An 1.89TOPS 1024 RV-cores 4MiB shared-L1 cluster for next-generation open-source software-defined radios,” in Proceedings of the Great Lakes Symposium on VLSI 2024 , ser. GLSVLSI ’24. New York, NY , USA: ACM, Jun. 2024, p. 86–91

    work page 2024

  8. [8]

    MemPool: A scalable manycore architecture with a low-latency shared L1 memory,

    S. Riedel, M. Cavalcante, R. Andri, and L. Benini, “MemPool: A scalable manycore architecture with a low-latency shared L1 memory,” IEEE Transactions on Computers, vol. 72, no. 12, pp. 3561–3575, 2023

    work page 2023

Show all 26 references
  1. [9]

    50 years of microprocessor trend data,

    K. Rupp, “50 years of microprocessor trend data,” https://github .com/ karlrupp/microprocessor-trend-data, 2022

    2022

  2. [10]

    A clustered manycore processor architecture for embedded and accelerated applications,

    B. D. de Dinechin et al., “A clustered manycore processor architecture for embedded and accelerated applications,” in 2013 IEEE High Performance Extreme Computing Conference (HPEC) , 2013, pp. 1–6

    2013

  3. [11]

    COOLIDGE ™ MPPA® DPU Kalray’s unique processor architecture,

    B. D. de Dinechin and L. Hamon, “COOLIDGE ™ MPPA® DPU Kalray’s unique processor architecture,” https://www .kalrayinc.com/wp-content/ uploads/2023/10/WP Kalray MPPA DPU Coolidge june2022.pdf, Kalray Inc., Tech. Rep., 2022

    2023

  4. [12]

    Sievers et al., The CoreVA-MPSoC: A Multiprocessor Platform for Software-Defined Radio

    G. Sievers et al., The CoreVA-MPSoC: A Multiprocessor Platform for Software-Defined Radio. Springer, 2017, pp. 29–59

    2017

  5. [13]

    NVIDIA Fermi GPU architecture,

    NVIDIA Corporation, “NVIDIA Fermi GPU architecture,” https : / / www.nvidia.com / content / pdf / fermi white papers / nvidia fermi compute architecture whitepaper.pdf, NVIDIA Corp., Tech. Rep., 2010

    2010

  6. [14]

    NVIDIA GeForce GTX 680,

    ——, “NVIDIA GeForce GTX 680,” https://www .nvidia.com/content/pdf/ product-specifications/geforce gtx 680 whitepaper final.pdf, NVIDIA Corp., Tech. Rep., 2012

    2012

  7. [15]

    NVIDIA GeForce GTX 750 Ti,

    ——, “NVIDIA GeForce GTX 750 Ti,” https://fabiensanglard .net/cuda/ GeForce-GTX-750-Ti-Whitepaper .pdf, NVIDIA Corp., Tech. Rep., 2014

    2014

  8. [16]

    NVIDIA Tesla P100,

    ——, “NVIDIA Tesla P100,” https://images .nvidia.com/content/pdf/tesla/ whitepaper/pascal-architecture-whitepaper .pdf, NVIDIA Corp., Tech. Rep., 2016

    2016

  9. [17]

    NVIDIA Turing GPU architecture,

    ——, “NVIDIA Turing GPU architecture,” https://images .nvidia.com/ aem- dam/en- zz/Solutions/design- visualization/technologies/turing- architecture/NVIDIA-Turing-Architecture-Whitepaper .pdf, NVIDIA Corp., Tech. Rep., 2018

    2018

  10. [18]

    NVIDIA Ada GPU architecture,

    ——, “NVIDIA Ada GPU architecture,” https://images .nvidia.com/aem- dam/Solutions/Data-Center/l4/nvidia-ada-gpu-architecture-whitepaper- V2.02.pdf, NVIDIA Corp., Tech. Rep., 2022

    2022

  11. [19]

    Message passing or shared memory: Evaluating the delegation abstraction for multicores,

    I. Calciu et al. , “Message passing or shared memory: Evaluating the delegation abstraction for multicores,” in Principles of Distributed Systems . Cham: Springer International Publishing, 2013, pp. 83–97

    2013

  12. [20]

    Towards energy-efficient database cluster design,

    W. Lang, S. Harizopoulos, J. M. Patel, M. A. Shah, and D. Tsirogiannis, “Towards energy-efficient database cluster design,” Proc. VLDB Endow., vol. 5, no. 11, pp. 1684–1695, Jul. 2012

    2012

  13. [21]

    Exploration of distributed shared memory architectures for noc-based multiprocessors,

    M. Monchiero, G. Palermo, C. Silvano, and O. Villa, “Exploration of distributed shared memory architectures for noc-based multiprocessors,” in 2006 International Conference on Embedded Computer Systems: Architectures, Modeling and Simulation , 2006, pp. 144–151

    2006

  14. [22]

    Analysis of double buffering on two different multicore architectures: Quad-core opteron and the cell-be,

    J. C. Sancho and D. J. Kerbyson, “Analysis of double buffering on two different multicore architectures: Quad-core opteron and the cell-be,” in 2008 IEEE International Symposium on Parallel and Distributed Processing, 2008, pp. 1–12

    2008

  15. [23]

    DCT-based OTFS with reduced PAPR,

    N. V . Kalpage, P. Priya, and Y . Hong, “DCT-based OTFS with reduced PAPR,” IEEE Communications Letters , vol. 28, no. 1, pp. 158–162, 2024

    2024

  16. [24]

    A novel ISAC transmission framework based on spatially- spread orthogonal time frequency space modulation,

    S. Li et al., “A novel ISAC transmission framework based on spatially- spread orthogonal time frequency space modulation,” IEEE Journal on Selected Areas in Communications , vol. 40, no. 6, pp. 1854–1872, 2022

    2022

  17. [25]

    Efficient parallelization of 5G-PUSCH on a scalable RISC-V many-core processor,

    M. Bertuletti, Y . Zhang, A. Vanelli-Coralli, and L. Benini, “Efficient parallelization of 5G-PUSCH on a scalable RISC-V many-core processor,” in 2023 Design, Automation, and Test in Europe Conference and Exhibition . Antwerp, Belgium: IEEE, Apr. 2023, pp. 396–401

    2023

  18. [26]

    Fast shared-memory barrier synchronization for a 1024-cores RISC-V many-core cluster,

    M. Bertuletti, S. Riedel, Y . Zhang, A. Vanelli-Coralli, and L. Benini, “Fast shared-memory barrier synchronization for a 1024-cores RISC-V many-core cluster,” in Embedded Computer Systems: Architectures, Modeling, and Simulation. Samos: Springer Nature Switzerland, Jul. 2023,...

    2023

Pith tools

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