{"id":"b92e6b1e-e98c-4986-a3b9-6ae5e9658b9b","arxiv_id":"2411.12710","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A travel-time-based uneven task mapper for NoC-based DNN accelerators reduces simulated inference latency by up to 12.1% per layer and 8.17% for LeNet over even row-major mapping.","lead":"This paper proposes a task-mapping method for NoC-based DNN accelerators that assigns uneven numbers of computation tasks to processing elements based on measured travel times, including a runtime sampling version. In simulations on a 4x4 NoC running LeNet, it reports up to 12.1% layer-level latency improvement and 8.17% whole-model improvement over row-major mapping without an extra run.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central claim depends on Eq. (4)'s stationarity assumption: per-PE travel time measured under row-major sampling is treated as fixed after task reallocation, although congestion is mapping-dependent. This assumption is untested, so the 8.17% whole-LeNet gain is not robust to its failure.","rationale":"The reader's verdict was CONDITIONAL with medium correctness risk, and the reader's weakest assumption was exactly the stationarity of measured travel time under reallocation. I agree with that identification. Other weaknesses in the paper—no error bars, no released artifact, weak baselines—are evaluation limitations rather than direct threats to the central claim. The central claim is empirical: travel-time-based mapping reduces latency in the reported simulator experiments. The measured unevenness reduction to 5.81% is evidence that Eq. (4) worked approximately in the tested configurations. However, the paper never reports a post-remap travel-time comparison, so the one-shot sampling-window mapping could be miscalibrated in untested configurations such as higher task counts or different MC counts. The fixed-point check I propose would settle whether the mapping is self-consistent. Since this is a concrete, testable gap rather than a demonstrated failure, the appropriate verdict remains CONDITIONAL; I see no grounds to reject the paper's claim outright, nor to accept it as established.","tokens_in":9333,"tokens_out":8244,"duration_ms":87429,"concrete_test":"Use the existing cycle-accurate simulator to iterate the sampling-window mapping to a fixed point on the LeNet workload: start from row-major mapping, sample T_s per PE, solve Eqs. (7)-(8), simulate the remapped layer, re-measure per-PE travel times, and re-solve the mapping until the task-count vector converges or oscillation is detected. Compare the converged whole-LeNet latency with the one-shot 8.17% result from Section 5.6. If the one-shot result is materially worse than the converged result, or if the iteration diverges, the stationarity assumption is violated and the reported gain is not robust; if the one-shot result matches the converged result within a small tolerance, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Load-bearing concern: Eqs. (4) and (7) equalize Taskcount_i * Ttravel_i across PEs using travel times measured while the current (row-major) mapping is in place. However, Ttravel in Eq. (3) includes memory-access delay and NoC queuing/congestion components, both of which depend on how many tasks each PE injects and where that traffic goes. After tasks are reallocated toward low-travel-time PEs, those PEs inject more traffic and the shared MCs and router buffers experience different load, so the per-PE travel-time vector can shift. If it shifts, the sampling-window solution of Eqs. (7)-(8) is miscalibrated and the reported 8.17% improvement in Section 5.6 is not a stable property of the method. The paper's post-mapping unevenness of 5.81% in Section 5.2 suggests the approximation held in the tested configurations, but no reported check compares the T_s values used in Eq. (7) with the travel times actually experienced after remapping. The gap between the sampling-window result (8.17%) and the post-run result (10.37%) is also consistent with miscalibration, not solely with finite sampling noise.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a travel-time-based task mapping method for NoC-based DNN accelerators. Instead of assigning equal task counts, it allocates tasks to PEs in inverse proportion to measured per-task travel time (Eq. 4), so that each PE's total time is roughly equalized. The travel time includes request, memory-access, response, and computation components (Eq. 3). To avoid an extra run, the authors sample travel times during runtime using a sampling window (Eqs. 7-8) and apply the resulting ratios to residual tasks. Experiments on a cycle-accurate simulator compare against row-major and distance-based mappings across mapping iterations, packet sizes, and two NoC architectures, reporting improvements up to 12.1% for a single layer and 8.17% for the full LeNet with sampling window 10, versus 10.37% for post-run ideal mapping.","tokens_in":9603,"tokens_out":6011,"duration_ms":52088,"significance":"The work addresses a practical problem and has some strengths: it targets a real bottleneck (load imbalance in NoC-based accelerators), introduces a simple runtime-sampling mechanism that avoids an extra execution, and evaluates over multiple configurations including different architectures. The simulator results consistently show improvements over both baselines. However, the central equalization rule is a heuristic whose optimality is not derived, and the key stationarity assumption—that travel times remain valid after task reallocation—is not validated. The reported gains are plausible but not yet robustly supported. No code or artifacts are provided, so reproducibility relies on the textual description.","major_comments":[{"comment":"The mapping rule assumes each PE's total time equals Taskcount * Ttravel and that Ttravel is independent of the task allocation. However, Ttravel in Eq. (3) contains Treq and Tresp, which include NoC queuing and congestion delays, and these depend on how many tasks each PE injects and where the traffic goes. After reallocating tasks toward low-travel-time PEs, those PEs inject more traffic and the shared memory controllers and routers experience different load, so the per-PE travel-time vector can shift. The paper never reports a check comparing the Ttravel values used in Eq. (4)/(7) with the travel times actually experienced after remapping. I request such a validation (e.g., a table or scatter plot of predicted vs. actual per-PE completion times) or a sensitivity analysis that perturbs the travel-time vector; without this, the 8.17% whole-LeNet improvement is not established as a stable property of the method.","section":"§4.2, Eqs. (4) and (7)-(8)"},{"comment":"The gap between the sampling-window result (8.17%) and the post-run result (10.37%) is attributed to sampling noise, but it could equally reflect a systematic bias from using travel times measured under the old mapping. A concrete way to separate these effects is to run the sampling-window algorithm with increasing window sizes and check whether the improvement saturates at 10.37% or at a lower value; the paper currently tests only windows 1, 5, and 10, which is insufficient to distinguish the two hypotheses.","section":"§5.6"},{"comment":"All reported numbers appear to come from a single simulation run per configuration, and no error bars, confidence intervals, or seed variations are provided. Since the claimed improvements (8-12%) are modest and the paper is about congestion-dependent behavior, the results need to be shown to be stable across repeated runs (or the simulator's determinism must be justified). This is required before the quantitative headline claims can be accepted.","section":"§5.1 and §5.6"},{"comment":"The statement that 'ideally, the overall latency is balanced' by Eq. (4) is asserted rather than derived. Equalizing Taskcount * Ttravel per PE is a plausible load-balancing heuristic, but it is not obviously optimal for makespan on a shared NoC, where interactions between PEs matter. Please either provide a derivation or explicitly frame the method as a heuristic; the word 'ideal' for post-run mapping in §5.6 and the abstract should be adjusted accordingly.","section":"§4.2, Eq. (4)"}],"minor_comments":[{"comment":"The sentence 'For a complete NN example, our method achieves 10.37% and 13.75% overall improvements...' is confusing because 10.37% is later identified as the post-run (ideal) result, while the runtime sampling-window result is 8.17%. Please attribute the numbers to the correct variants.","section":"Abstract"},{"comment":"The distance values are labels (1, 2, 3), not continuous variables; the notation 'Taskcount1 * Distance1 = ...' should be explained more explicitly to avoid implying that Distance is a numeric multiplier.","section":"§3.3, Eq. (1)"},{"comment":"The text 'Nodes 13, 5, and 8 are the fastest as they have only one distance' should read 'distance 1'; also, the subfigures of Fig. 7 are not individually referenced in the text, making it hard to map the discussion to the panels.","section":"§5.2"},{"comment":"Numbers such as 'up to 12.1%' for one layer, '9.7%' for mapping iterations, and '8.17%' for the whole LeNet should be cross-checked for consistency with figures; there is no table summarizing all results, which would help.","section":"§5.4 and §5.6"},{"comment":"The paper would benefit from a notation table or glossary for Ttravel, Ts, Taskcount, and SamplingWindowLength; these are introduced across Sections 4.1-4.2 and used later without restatement.","section":"§4.1-4.2"},{"comment":"Minor language issues: 'the travel time recorded in the sampling window' and 'sampling window 10' are used interchangeably; choose one phrasing consistently.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a reasonable engineering contribution but is currently more suitable for a workshop or short conference paper than a journal; the missing validation of the stationarity assumption is the main technical gap, and the absence of variance reporting weakens the quantitative claims. The authors should also reconcile the abstract's attribution of the 10.37% number. If the requested experiments are performed and the framing is corrected, the paper could be acceptable."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The short version: this is a solid, incremental paper. The new part is using a short sampling window to measure per-PE travel times during a run, then allocating remaining tasks inversely proportional to those times. That is simple and genuinely useful. On their simulator it beats row-major and distance-based mapping across the tested configurations, cutting unevenness from ~22% to ~6% and improving whole-LeNet latency by 8.17% with a sampling window of 10, close to the 10.37% post-run ideal.\n\nWhat the paper does well: the problem is clearly motivated, the method is easy to understand, and the evaluation covers meaningful axes — mapping iterations, packet size, and NoC architecture. The authors are honest about the trade-off between sampling window length and accuracy, and they show that a too-small window can hurt. The comparison to static-latency mapping is useful: it demonstrates why purely analytical estimates fail once congestion matters. The paper is written plainly and does not oversell itself except for a slightly confusing abstract where the post-run numbers are listed before the runtime ones.\n\nThe soft spot, and it is load-bearing: Eq. (4) assumes the travel time measured under the current mapping stays valid after tasks are reallocated. But travel time includes queuing and congestion, which depend on where the traffic is injected. If moving tasks to faster PEs congests those paths, the equalization is miscalibrated. The paper does not check whether the sampled travel times actually match what PEs experience after remapping. The gap between the 8.17% sampled result and the 10.37% post-run ideal could be sampling noise, but it could also be exactly this miscalibration. This is not fatal — the post-mapping unevenness of 5.81% suggests the approximation held in their configurations — but it needs a direct test. A simple experiment measuring travel times after remapping and comparing them to the sampled values would settle it.\n\nSmaller issues: baselines are only row-major and distance-based; no comparison with work-stealing or other adaptive heuristics, which the authors acknowledge as future work. The simulator results have no error bars or repeated-run statement, though a cycle-accurate simulator is likely deterministic. No code or data is released, so reproducibility is limited to what is in the paper.\n\nOverall: this deserves a serious referee. The idea is practical, the experiments are reasonably thorough, and the stationarity assumption is the one thing I would want pinned down before publication. If that check passes, this is a citable engineering contribution for NoC-based DNN accelerators.","headline":"A practical, incremental runtime mapping heuristic for NoC-based DNN accelerators; the simulator results are consistent, but the load-bearing stationarity assumption needs explicit validation before I'd trust the numbers.","tokens_in":10103,"tokens_out":2281,"would_cite":true,"duration_ms":23902,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that assigning DNN tasks to NoC processing elements in proportion to measured travel time—rather than evenly or by distance—balances workload and cuts single-layer latency by up to 12.1% and whole-model latency by 8.17%…","keywords":["task mapping","network-on-chip","DNN accelerator","load balancing","travel time","sampling window","latency reduction","convolutional neural network"],"falsifier":"Run the sampling-window method on a NoC trace with bursty, non-stationary traffic, such as varying batch sizes or interleaved models, and compare each PE's final completion time against the equalized target. If the post-mapping unevenness significantly exceeds the 5.81% reported, or the whole-model speedup over row-major mapping drops below 8.17%, the stationarity assumption has failed. A direct check is to compare the travel-time ratios measured in the sampling window with those measured after reallocation: a large divergence means the mapping rule is chasing a moving target.","tokens_in":9157,"feed_emoji":"⏱️","tokens_out":10239,"duration_ms":79223,"temperature":0.7,"pith_summary":"Network-on-chip based DNN accelerators typically assign the same number of convolution tasks to every processing element, ignoring that PEs sit at different distances from memory and face different congestion. This paper proposes instead to allocate task counts in inverse proportion to each PE's observed travel time—the time for a request to reach memory, fetch the data, return, and compute—so that task count times travel time is roughly equal across PEs. The rebalancing is done at runtime by sampling travel times over a short window and then reassigning only the remaining tasks. In simulation, the method reduces single-layer latency by up to 12.1% compared with even and distance-based mapping, and whole-model latency by 8.17% with a ten-task sampling window, approaching the 10.37% gain of an ideal post-run mapping that uses exact travel times. The paper argues that because DNN tasks repeat similar patterns, a short sampling window is enough to capture the meaningful differences between PEs.","feed_headline":"Travel-time mapping cuts NoC DNN latency by up to 12%","feed_subtitle":"Sampling per-PE travel time and redistributing tasks cuts LeNet latency by 8.17%, close to the 10.37% ideal.","key_machinery":"The load-bearing rule is the equalization identity $T_{\\mathrm{askcount}}\\_i \\cdot T_{\\mathrm{travel}}\\_i = \\mathrm{constant}$ (Eq.~4), solved together with the total-task constraint to yield per-PE task counts. For runtime operation, the paper replaces the unmeasured exact travel time with a sampled time $T_s$ from a short sampling window and rebalances only the residual tasks (Eqs.~7--8). The travel-time decomposition $T_{\\mathrm{travel}} = T_{\\mathrm{req}} + T_{\\mathrm{mem\\_access}} + T_{\\mathrm{resp}} + T_{\\mathrm{comp}}$ is the mechanism that makes one scalar per PE encode both architecture and congestion. The sampling-window length is the trade-off knob: whole-model improvement grows from 1.78% (window 1) to 8.17% (window 10), approaching the post-run ideal of 10.37%.","core_discovery":"The central discovery is that the per-PE travel time, $T_{\\mathrm{travel}} = T_{\\mathrm{req}} + T_{\\mathrm{mem\\_access}} + T_{\\mathrm{resp}} + T_{\\mathrm{comp}}$, is a sufficient statistic for allocating convolution tasks in a NoC-based DNN accelerator. Allocating task counts so that $T_{\\mathrm{askcount}}\\_i \\times T_{\\mathrm{travel}}\\_i$ is constant across PEs (Eq.~4) nearly equalizes per-PE completion times, cutting the unevenness of per-task completion time from 22.09% under row-major mapping to 5.81% under the proposed mapping. The method works because travel time implicitly encodes both the static NoC topology (distance to memory controllers) and dynamic congestion, which pure distance-based or static-latency mappings miss. A runtime sampling window of ten tasks achieves 8.17% whole-model improvement, while a post-run mapping using exact recorded travel times achieves 10.37%, both relative to row-major mapping; the gap reflects that sampled travel times are only approximations of the true post-reallocation values.","pith_inferences":["The stationarity assumption—that travel times measured under the current mapping remain valid after tasks are reallocated—is the fragile point: if congestion shifts substantially after rebalancing, the equalization is miscalibrated. The paper's own 8.17% versus 10.37% gap is a partial measure of this effect.","The method is designed for the regular, repetitive traffic of CNN layers, which the paper notes makes predictions accurate. A testable extension is applying it to transformer or attention workloads whose communication patterns are input-dependent; the sampling window may need to be much longer or adaptive there.","The residual-task rebalancing means the benefit scales with layer size: small layers like the 84-packet layer already show degradation at short windows, so for tiny layers a fully static mapping or a post-run approach would be preferable—a policy the paper only implicitly hints at.","The post-run ideal could be approached at runtime by predicting congestion-aware travel times (e.g., from queue occupancy) rather than purely sampling history; a longer window only averages the past, it does not anticipate the future."],"forward_implications":["A layer's completion time is set by its slowest PE, so cutting per-PE unevenness from 22.09% to 5.81% yields latency improvements of 9.7% to 12.1% across the tested mapping iterations, packet sizes, and NoC topologies.","Because the method needs no extra run and only a short sampling window, it can be applied on the fly during inference, with window length as a tunable knob: longer windows give better approximations but require more samples before rebalancing.","The benefit shrinks when the NoC has more memory controllers: with four MCs the improvement drops to 5.6% because the distance variance between PEs is smaller, leaving less room for rebalancing.","A post-run mapping that uses exact travel times is the upper bound of what any runtime estimator can achieve, so the 10.37% figure bounds the potential of sampling-based approaches for this architecture.","Distance-based mapping can sometimes be worse than even mapping, showing that static topology information alone is insufficient; only travel time that includes dynamic congestion captures the true cost."],"supporting_citations":[{"why":"Supplies the virtual-channel network model that serves as the interconnection fabric in the cycle-accurate simulator.","marker":"[1]"},{"why":"The even-mapping scheme used as the row-major baseline that the proposed method improves upon.","marker":"[6]"},{"why":"The complete neural network model whose whole-model inference time is used to measure end-to-end improvement.","marker":"[11]"},{"why":"Provides the per-PE MAC-count and NoC clustering configuration used in the simulator.","marker":"[18]"},{"why":"Supplies the base network-on-chip simulation environment that the experiments extend with the CNN workload.","marker":"[20]"},{"why":"Fixes the processing-element clock frequency used in the performance model.","marker":"[8]"},{"why":"Fixes the memory bandwidth specification used to compute memory access delay.","marker":"[15]"}],"fun_headline_variants":["Travel-time task mapping beats distance-based by 13.75%","Sampled travel times give 8.17% whole-NN speedup on NoC","NoC DNN latency cut up to 12.1% with travel-time mapping","Travel time trumps distance for NoC DNN mapping","Congestion-aware mapping yields 12.1% peak NoC DNN gain"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the travel time measured on a PE before reallocation remains valid after tasks are repartitioned, even though network congestion depends on the mapping itself; if travel times shift substantially after rebalancing, the equalization is miscalibrated and the reported gains degrade.","fun_headline_variants_meta":{"raw":{"variants":["Travel-time task mapping beats distance-based by 13.75%","Sampled travel times give 8.17% whole-NN speedup on NoC","NoC DNN latency cut up to 12.1% with travel-time mapping","Travel time trumps distance for NoC DNN mapping","Congestion-aware mapping yields 12.1% peak NoC DNN gain"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001651,"raw_usage":{"total_tokens":6580,"prompt_tokens":994,"completion_tokens":5586,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":610,"completion_tokens_details":{"reasoning_tokens":5485}},"tokens_in":610,"tokens_out":5586,"duration_ms":37250,"temperature":1.0,"reasoning_tokens":5485,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T17:13:10.020963+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the sampling-window method on a NoC trace with bursty, non-stationary traffic, such as varying batch sizes or interleaved models, and compare each PE's final completion time against the equalized target. If the post-mapping unevenness significantly exceeds the 5.81% reported, or the whole-model speedup over row-major mapping drops below 8.17%, the stationarity assumption has failed. A direct check is to compare the travel-time ratios measured in the sampling window with those measured after reallocation: a large divergence means the mapping rule is chasing a moving target.","supporting_citations":[{"cited_title":"CiFlow: Dataflow Analysis and Optimization of Key Switching for Homomorphic Encryption","cited_arxiv_id":"2311.01598","evidence_quote":"Fixes the memory bandwidth specification used to compute memory access delay."},{"cited_title":"In: 2009 IEEE international symposium on performance analysis of systems and software","cited_arxiv_id":null,"evidence_quote":"Supplies the virtual-channel network model that serves as the interconnection fabric in the cycle-accurate simulator."},{"cited_title":"IEEE Journal on Emerging and Selected Topics in Circuits and Systems9(2), 292–308 (2019)","cited_arxiv_id":null,"evidence_quote":"The even-mapping scheme used as the row-major baseline that the proposed method improves upon."},{"cited_title":"In: Proceedings of the 52nd An- nual IEEE/ACM International Symposium on Microarchitecture","cited_arxiv_id":null,"evidence_quote":"Provides the per-PE MAC-count and NoC clustering configuration used in the simulator."},{"cited_title":"IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems41(5), 1523–1536 (2021)","cited_arxiv_id":null,"evidence_quote":"Supplies the base network-on-chip simulation environment that the experiments extend with the CNN workload."},{"cited_title":"ACM Transactions on Embedded Computing Systems (2022)","cited_arxiv_id":null,"evidence_quote":"Fixes the processing-element clock frequency used in the performance model."}],"review_version":1}