{"id":"89f5ebad-f894-4d57-ad98-79c8b64bc81d","arxiv_id":"2607.22869","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A multi-primitive in-memory pipeline executes all four MCTS phases on chip, reaching a simulated 60 mW, 96x energy efficiency over CPU, and 3-kyu Go strength.","lead":"This paper maps each phase of a popular game-search algorithm onto a different in-memory computing circuit, so the search never leaves the chip. In simulation, the design runs 9x9 Go at about 60 milliwatts, nearly 100 times more energy-efficient than a CPU, while matching two open-source Go engines in playing strength.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The single strongest claim — 96x energy efficiency at ~60 mW — rests entirely on one deterministic simulation run with no fabricated chip; the load-bearing uncertainty is the unvalidated digital-logic power estimate.","rationale":"The reader correctly identified the energy and power figures as the weakest assumption, and I agree that a CONDITIONAL verdict is appropriate because the numeric claim is not yet experimentally pinned by a fabricated chip. My disagreement is only in specificity: the reader emphasized the overall synthetic/scaling flow, whereas I am pointing at the component-level breakdown, which shows that the analog crossbar (the 'IMC' part) contributes only 1.54 mW of the 60.26 mW, while the unvalidated digital logic (CAM, GLU, FSM) contributes 55.43 mW. This matters because the paper's central claim is about in-memory computing enabling milliwatt-scale search; if the digital logic power is underestimated by the synthesis-plus-scaling flow, the headline advantage shrinks. The authors themselves acknowledge the lack of silicon validation in the limitations section, which is honest but does not remove the uncertainty. The Go-strength and cross-domain results are well-qualified by the paper and are not the load-bearing concern. The internal inconsistency in evaluator training budgets (Methods says 2,000 positions for the cross-domain networks, while the tournament section says 10 iterations of ~35,000 positions each for IMC-strong) is a real presentation issue but does not, by itself, change the central argument; the 350k-position IMC-strong training is only used for the Go strength comparison, not for the energy claim. The most decisive check is independent post-layout or silicon verification of the digital power components, so I keep the verdict CONDITIONAL rather than moving to ACCEPT or REJECT.","tokens_in":33961,"tokens_out":1953,"duration_ms":16016,"concrete_test":"Independently re-run the Synopsys Design Compiler flow at 65nm and then compare the reported 65nm-to-22nm Stillmaker-scaled CAM selection, GLU expansion, and FSM control power (14.82 + 28.11 + 12.50 = 55.43 mW) against either (a) a measured 22nm or 65nm test chip running the same four-stage pipeline, or (b) an independent post-layout simulation with extracted RC parasitics at 22nm. If the digital logic power shifts by more than 50%, the 60.26 mW headline and the 96x figure would need to be re-baselined, even if the architectural mapping remains valid.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The reader's weakest assumption targets the 22nm energy and power figures overall. I think the more precise weak spot is the internal composition of the power model: Supplementary Table S3 reports nearly all of the 60.26 mW coming from digital logic (CAM selection 14.82 mW, GLU expansion 28.11 mW, FSM control 12.50 mW, backprop SRAM 3.03 mW), with the analog RRAM crossbar contributing only 1.54 mW. These digital figures come from Synopsys synthesis at 500 MHz against a TSMC 65nm library scaled to 22nm via Stillmaker, a flow that is not a substitute for measured silicon power. The paper's own limitations section acknowledges that end-to-end silicon validation of the CAM–crossbar interaction at full pipeline rate is the natural next step, and Extended Data Table 2 reports IMC-NN values from a deterministic single-run simulation with no error bars. The structural concern is therefore not that the authors are concealing uncertainty; it is that the headline 96x and ~60 mW numbers depend more on unvalidated synthesized logic and FSM power (55.4 mW of the 60.26 mW total) than on the analog in-memory crossbar that is the paper's architectural centerpiece. If the digital logic power is underestimated by the synthesis-plus-scaling flow, the headline efficiency advantage shrinks even though the phase-to-primitive mapping itself may remain entirely valid.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces phase-to-primitive decomposition, a four-step methodology (profile, match, reformulate, compose) for mapping phase-heterogeneous algorithms onto co-located in-memory computing primitives. Applied to Monte Carlo tree search, the selection, expansion, rollout, and backpropagation phases are mapped to content-addressable memory, a combinational Game Logic Unit, an RRAM crossbar neural evaluator, and in-place SRAM updates, respectively, under a TCAM-based finite-state-machine controller. At a simulated 22 nm technology node, the resulting IMC-MCTS accelerator is reported to consume roughly 60 mW of sustained power at 9x9 Go, to achieve 96x energy efficiency over a CPU and 65x-2,059x over an H100 GPU, and to reach an EGF tournament rating of about 1727, within sample-size uncertainty of the open-source engines Pachi-UCT and Michi-C at 500 simulations per move. The same parameterized RTL is evaluated on eight grid-based applications across four domains. All IMC energy and power figures come from cycle-accurate SST simulation with RTL synthesized at 65 nm and scaled to 22 nm via Stillmaker, using crossbar parameters from fabricated 180 nm arrays; no 22 nm chip was fabricated.","tokens_in":34187,"tokens_out":7167,"duration_ms":57489,"significance":"If the quantitative results hold, this is a significant contribution: it is, to my knowledge, the first demonstration that an irregular, multi-phase algorithm such as MCTS can be mapped end-to-end onto a multi-primitive in-memory computing substrate, and the paper supports this with unusually detailed RTL, synthesis, simulation, and verification methodology. The decision-quality comparison against external engines, the explicit noise-robustness analysis, the ablation study, and the plan for public code release are all strengths. The central architectural claim, that phase-to-primitive decomposition can make MCTS IMC-compatible, is well supported by the design and by the tournament results at matched 500-simulation compute. However, the headline energy and power figures rest on digital-logic power estimates that contribute roughly 97% of the reported 60.26 mW and have not been validated by silicon measurement; the quantitative efficiency claims should therefore be read as projections until sensitivity analysis or measured data are provided.","major_comments":[{"comment":"The headline sustained power of 60.26 mW and the resulting 96x energy-efficiency claim depend almost entirely on digital-logic power estimates that have not been validated by measurement: Supplementary Table S3 assigns 14.82 mW to CAM selection, 28.11 mW to GLU expansion, 12.50 mW to FSM control, and 3.03 mW to backprop SRAM out of the 60.26 mW total, with only 1.54 mW attributed to the RRAM crossbar, and Extended Data Table 2 reports all IMC energy values from a single deterministic simulation run with no variance. Because the digital numbers come from Synopsys synthesis at 65 nm scaled to 22 nm via Stillmaker and the crossbar timing comes from a fabricated 180 nm array scaled to 22 nm, an underestimate of digital power or peripheral energy would directly shrink the headline 96x advantage. I request either end-to-end silicon validation or, at minimum, a systematic sensitivity analysis covering PVT corners, alternative scaling assumptions, and a plausible range of digital-power error, with uncertainty intervals reported on all IMC energy and power numbers.","section":"Methods, 'IMC-MCTS architecture and synthesis'; Supplementary Table S3; Extended Data Table 2"},{"comment":"The claim that IMC-strong plays at the level of Pachi-UCT is weakened by a training/evaluation overlap: IMC-strong's evaluator was trained by iteratively sparring against Pachi-UCT (10 iterations of about 35,000 positions each, per the Tournament evaluation section), and the same Pachi-UCT is then used as a head-to-head reference in the 1,050-game tournament. This makes the comparison at least partly a measure of how well the hardware mimics its training opponent rather than an independent strength estimate. I recommend either training IMC-strong without Pachi-UCT and comparing against engines not used in training, or explicitly discussing this circularity as a limitation of the relative-ordering claim.","section":"Methods, 'Tournament evaluation'; Results, 'Decision quality on Go'"},{"comment":"The statement that 'the same hardware' runs all eight applications is stronger than what the methods support: per-application customization is described as a single-pass digital synthesis in which board size and encoding parameters re-size the CAM, GLU, SRAM, and crossbar arrays, and the cross-domain evaluation protocol states that hardware area and energy were computed using the parameterized synthesis model. The accurate claim is that the same parameterized RTL and pipeline are reused across applications, not that one instantiated chip executes all eight tasks. Please reword the text accordingly, including the abstract's 'same substrate' phrasing, and reconcile the statement that only crossbar weights are reprogrammed with the statement that per-application synthesis-time parameters are changed.","section":"Results, 'Substrate reusability across grid-based decision tasks'; Methods, 'IMC-MCTS architecture and synthesis' and…"},{"comment":"There is an inconsistency in the reported training-set sizes: the crossbar modeling section says networks are trained on 2,000 labeled positions per board size, while the tournament section describes IMC-strong as trained over 10 iterations of about 35,000 positions each, which totals roughly 350,000 positions. The distinction matters because the paper attributes IMC-strong's Elo gap over IMC-weak to training-data quality. Please clarify which budget applies to IMC-strong, whether the 2,000-position budget in Extended Data Table 3 refers only to the cross-domain demonstration networks, and how the 2,000-position networks relate to the 60% three-class accuracy reported for 9x9 Go.","section":"Methods, 'Crossbar device modeling' and 'Tournament evaluation'"}],"minor_comments":[{"comment":"The phrase '10 170 legal positions' should read '10^170 legal positions'; the superscript formatting is missing in the arXiv rendering.","section":"Abstract"},{"comment":"The Low, Medium, and High play-strength labels in Fig. 2e are not defined in the caption; please state that they correspond to the iteration budgets listed in Supplementary Table S1.","section":"Fig. 2e caption"},{"comment":"The energy comparison uses a 5,000-iteration-per-move budget while the tournament uses 500 simulations per move; please make this explicit in the Extended Data Table 2 caption and in the Fig. 3 legend so readers do not confuse the two budgets.","section":"Methods, 'Baselines and energy measurement'; Extended Data Table 2 caption"},{"comment":"The SGG threshold of +0.05 is appropriately described as an indicative policy-lift cutoff rather than a statistical significance boundary, and the smaller lifts are flagged as directional; however, consider reporting per-application game-level variance or confidence intervals so readers can see the uncertainty in values such as +0.09 for Go.","section":"Supplementary Note 9.3, Eq. S3"},{"comment":"The abstract's phrase 'fabricated RRAM-array parameters' could mislead readers into thinking the RRAM arrays were fabricated at 22 nm; please clarify that the arrays were fabricated at 180 nm and scaled to 22 nm, with the scaling assumptions stated.","section":"Abstract and Methods, 'Crossbar device modeling'"},{"comment":"The manuscript promises a Zenodo deposit upon publication but provides no anonymous review link or DOI; since the energy claims are simulation-based, providing the simulator, RTL, and trained weights to reviewers during the review process would materially support verification.","section":"Data and code availability"},{"comment":"The phrase 'at matched 500-simulation compute' applies to the MCTS engines but not to KataGo, which uses its default playout schedule; please specify that KataGo is not iso-compute in the main text or figure caption.","section":"Results, 'Decision quality on Go'"}],"recommendation":"major_revision","confidential_remarks":"The paper is unusually honest about its limitations, which is a strength, but I am concerned that the headline 60 mW and 96x efficiency figures will be read by non-specialists as measured silicon results rather than simulation projections. The abstract and summary should state clearly that these numbers come from a 65 nm synthesis scaled to 22 nm and a single deterministic simulation run, not from a fabricated chip. The novelty claim regarding first multi-primitive IMC for MCTS appears sound relative to the cited prior work, and the architectural ideas are worth publishing once the energy claims are either validated or properly qualified with uncertainty bounds."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I read this one carefully and think it deserves a serious referee, but the referee should keep the claims and the evidence separate. What is actually new: the phase-to-primitive decomposition, mapping MCTS selection/expansion/rollout/backprop onto CAM, combinational logic, RRAM crossbar, and SRAM. I checked the 12-work survey in Table S6 and it holds up — no prior MCTS accelerator used IMC in any phase, and prior IMC accelerators each deploy one primitive for homogeneous workloads. The load-bearing composition story, where each primitive depends on the others' timing guarantees, is a real organizing idea, and the ablation study in Note 7 makes it concrete. Credit is also due for the explicit limitations section and the noise-robustness analysis with 1-ply agreement versus end-to-end win rate; that is the kind of honest reporting that lets a referee calibrate fast.\n\nThe soft spots are real and mostly where the reader put them. All energy and power numbers come from one deterministic cycle-accurate simulation, with no fabricated chip and no variance reported. The stress-test note is right to sharpen the concern: of the 60.26 mW, 55.4 mW is digital logic (CAM selection, GLU, FSM, backprop SRAM) synthesized at 65nm and scaled to 22nm via Stillmaker, while the analog crossbar is only 1.54 mW. So the headline efficiency depends more on unvalidated synthesized logic than on the IMC centerpiece. That does not kill the paper's contribution — the mapping and composition stand on their own — but the 96x figure should be presented as a model projection with error bars or explicit scaling uncertainty, not as a measured operating point.\n\nTwo smaller points. The tournament ratings at 50 games per pairing are genuinely within sample-size uncertainty; the paper says as much, and I would not let an overstrong summary survive peer review. And the training-budget inconsistency the reader flags is mostly a clarity problem, not a contradiction: the Methods paragraph about 2,000 positions refers to the cross-domain demonstration networks, while IMC-strong uses ~350k self-play positions. The prose needs to separate those two regimes explicitly, because a referee will trip on it exactly the way we did. The +0.05 SGG cutoff is explicitly labeled as an indicative policy-lift threshold rather than a significance boundary, which is defensible for a substrate-reusability demonstration.\n\nWho gets value: anyone working on IMC acceleration, MCTS hardware, or edge AI planning. I would bring it to a reading group and would cite the decomposition methodology in my own work. My recommendation is to send it to peer review with an instruction that the simulator-derived numbers be clearly marked as projections and the training regimes untangled. The architecture contribution is solid enough to warrant that referee time even though the headline chip numbers are not yet established.","headline":"Phase-to-primitive decomposition is a genuine contribution, but the headline 60 mW / 96x numbers are simulation projections whose weakest link is the synthesized digital logic, not the analog crossbar.","tokens_in":34837,"tokens_out":2087,"would_cite":true,"duration_ms":20537,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A multi-primitive in-memory design executes all four phases of Monte Carlo tree search at about 60 mW for 9-by-9 Go, with energy efficiency 96x better than a CPU and 65x–2,059x better than an H100 GPU.","keywords":["in-memory computing","Monte Carlo tree search","edge AI","neuromorphic computing","hardware-software co-design","RRAM crossbar","content-addressable memory","phase-to-primitive decomposition"],"falsifier":"Fabricate the 9-by-9 core at a modern node and measure sustained power and per-move energy during 5,000-iteration-per-move search; if measured power is substantially above the simulated ~60 mW or per-move energy is substantially above the simulated ~124 mJ, the 96x efficiency claim falls. A cheaper check would be to measure the CAM lookup latency and the 768-ns crossbar read in a test chip, since the whole pipeline depends on those two timing guarantees.","tokens_in":33718,"feed_emoji":"⚡","tokens_out":11027,"duration_ms":91590,"temperature":0.7,"pith_summary":"Monte Carlo tree search has been considered too irregular for in-memory computing because its four phases—selection, expansion, rollout, and backpropagation—demand qualitatively different operations. This paper claims that apparent incompatibility is not fundamental, introducing phase-to-primitive decomposition, which reformulates each phase as a hardware-native in-memory primitive and composes them into an on-chip pipeline. On 9-by-9 Go, the resulting IMC-MCTS design runs sustained 5,000-iteration-per-move search at roughly 60 mW, with 96x better energy efficiency than a CPU and 65x–2,059x over an H100 GPU depending on batch size. In a 1,050-game tournament at matched compute, it plays at about 1727 EGF, within sample-size uncertainty of the open-source engines Pachi-UCT and Michi-C. If the simulated energy figures survive silicon, the result would move search-based AI from data-center power budgets to milliwatt-scale embedded devices, and the same substrate already runs eight grid-based tasks across four AI domains.","feed_headline":"In-memory design runs Monte Carlo tree search at 60 milliwatts","feed_subtitle":"A four-primitive pipeline maps every search phase onto memory, reaching 96x CPU energy efficiency on 9-by-9 Go.","key_machinery":"The carrying object is phase-to-primitive decomposition, a four-step methodology—profile, match, reformulate, compose—that turns a phase-heterogeneous algorithm into a multi-primitive in-memory workload. For MCTS, it pairs each phase with a distinct hardware primitive: a 6T-SRAM content-addressable memory for $\\mathcal{O}(1)$ associative node lookup during selection, a combinational Game Logic Unit for single-cycle legal-move expansion, an analog RRAM crossbar with 8-bit ADC and binary 1-bit DAC encodings for the rollout evaluation, and SRAM with co-located saturating counter logic for in-place read-modify-write backpropagation. A TCAM-based finite-state machine orchestrates the four stages with deterministic timing, and the interlocking latencies (constant-time CAM lookup, fixed 768-ns crossbar read, in-place SRAM updates) are what make the end-to-end pipeline stay on chip. The decomposition is load-bearing: removing any one primitive would collapse the end-to-end gain.","core_discovery":"The core claim is that the obstacle to mapping irregular multi-phase algorithms onto in-memory computing is the choice of operating point, not a fundamental limit. The paper shows that Monte Carlo tree search can be executed entirely on co-located memory primitives: content-addressable memory performs selection by returning all children of a node in a single cycle; combinational logic generates legal moves for expansion; an RRAM crossbar carries out the neural rollout at 0.308 pJ per multiply-accumulate; and SRAM performs in-place backpropagation updates. The cycle-accurate, synthesis-based evaluation reports about 60 mW sustained power at 9-by-9 Go, 96x energy efficiency over the CPU baseline, and a rating of roughly 1727 EGF that sits between Pachi-UCT and Michi-C at matched 500-simulation compute. It also reports that the search ensemble absorbs RRAM conductance noise up to $\\sigma=10\\%$ without degrading win rate, because hundreds of rolled-out evaluations average out per-position perturbations.","pith_inferences":["One testable extension the authors leave implicit is whether the same phase-wise mapping works for continuous state spaces; the paper only demonstrates grid-representable tasks, so a natural follow-up is a non-grid domain such as continuous robot motion planning.","If the simulated 22-nm numbers hold on silicon, the technology's real ceiling may be training data rather than the analog substrate: the gap between the weak and strong evaluators suggests playing strength tracks evaluator quality, so stronger play should track larger training corpora and larger crossbars.","The broader editorial reading is that algorithmic decomposition, rather than ever-larger general-purpose accelerators, may be the scalable path to milliwatt-scale decision hardware for planning and neuro-symbolic workloads.","A direct silicon test of the two timing guarantees—single-cycle CAM lookup and the 768-ns crossbar read—would show whether the whole pipeline's fixed-latency composition survives real device variation."],"forward_implications":["Search-based decision-making can run at roughly 60 mW for 9-by-9 Go, a power class that supports drones, microcontroller-class planners, and duty-cycled wearable devices.","The same unmodified substrate, with only crossbar weights reprogrammed, executes eight grid-based tasks across strategy games, navigation, protein-folding optimization, and puzzles, all showing better play than random-rollout MCTS as measured by the paper's Search Guidance Gain.","Energy efficiency over conventional hardware holds across board sizes, with 96x over CPU and 65x–2,059x over the H100 GPU, plus a 3.4x latency advantage over the batched-256 H100 operating point at 9-by-9.","The search ensemble makes MCTS robust to analog-substrate noise: conductance noise up to 10% leaves win rates essentially unchanged even though single-position evaluations diverge.","Phase-to-primitive decomposition generalizes as a methodology to other control-flow-heavy algorithms whose phases admit primitive-compatible reformulations, such as constraint satisfaction, planning under partial observability, and neuro-symbolic reasoning."],"supporting_citations":[{"why":"It defines Monte Carlo tree search and its selection and backup operators, the algorithm being mapped onto hardware.","marker":"[1]"},{"why":"It introduces UCB1 bandit planning, the policy the selection phase implements.","marker":"[2]"},{"why":"It motivates replacing random rollouts with a fixed-latency neural evaluator via self-play-guided tree search.","marker":"[4]"},{"why":"It establishes in-memory computing with resistive devices as the paradigm the design extends.","marker":"[12]"},{"why":"It provides the RRAM non-ideality envelope and an in-memory chip reference for the analog rollout unit.","marker":"[13]"},{"why":"It supplies the fabricated 180-nm CMOS RRAM crossbar whose timing and device parameters are scaled to 22 nm.","marker":"[23]"},{"why":"It provides the cycle-accurate discrete-event simulation framework that produces the reported energy, power, and latency numbers.","marker":"[28]"},{"why":"It is the open-source MCTS engine used for the iso-compute comparison of playing strength.","marker":"[29]"},{"why":"It is the second open-source MCTS engine used for the same iso-compute strength comparison.","marker":"[30]"},{"why":"It supplies the technology scaling equations used to convert synthesized 65-nm results to 22 nm.","marker":"[35]"}],"fun_headline_variants":["Monte Carlo tree search runs on memory at 60 mW","Phase-to-primitive mapping puts entire MCTS on chip","In-memory MCTS beats CPU 96x, GPU up to 2059x","Memory-native MCTS: 0.308 pJ per MAC, 60 mW total","RRAM, SRAM, CAM: MCTS phases become memory operations"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The headline energy and power figures assume that the 22-nm numbers from cycle-accurate simulation—digital logic synthesized from a 65-nm library, SRAM modeled by a cache tool, and RRAM timing scaled from a fabricated 180-nm array—accurately predict a real chip.","fun_headline_variants_meta":{"raw":{"variants":["Monte Carlo tree search runs on memory at 60 mW","Phase-to-primitive mapping puts entire MCTS on chip","In-memory MCTS beats CPU 96x, GPU up to 2059x","Memory-native MCTS: 0.308 pJ per MAC, 60 mW total","RRAM, SRAM, CAM: MCTS phases become memory operations"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000891,"raw_usage":{"total_tokens":3852,"prompt_tokens":960,"completion_tokens":2892,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":576,"completion_tokens_details":{"reasoning_tokens":2790}},"tokens_in":576,"tokens_out":2892,"duration_ms":19184,"temperature":1.0,"reasoning_tokens":2790,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T15:28:56.469719+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Fabricate the 9-by-9 core at a modern node and measure sustained power and per-move energy during 5,000-iteration-per-move search; if measured power is substantially above the simulated ~60 mW or per-move energy is substantially above the simulated ~124 mJ, the 96x efficiency claim falls. A cheaper check would be to measure the CAM lookup latency and the 768-ns crossbar read in a test chip, since the whole pipeline depends on those two timing guarantees.","supporting_citations":[{"cited_title":"In: International Conference on Computers and Games, pp","cited_arxiv_id":null,"evidence_quote":"It defines Monte Carlo tree search and its selection and backup operators, the algorithm being mapped onto hardware."},{"cited_title":"In: Euro- pean Conference on Machine Learning (ECML), pp","cited_arxiv_id":null,"evidence_quote":"It introduces UCB1 bandit planning, the policy the selection phase implements."},{"cited_title":"Advanced Materials30(9), 1705914 (2018)","cited_arxiv_id":null,"evidence_quote":"It establishes in-memory computing with resistive devices as the paradigm the design extends."},{"cited_title":"Advanced Electronic Materials5(9), 1800876 (2019)","cited_arxiv_id":null,"evidence_quote":"It provides the RRAM non-ideality envelope and an in-memory chip reference for the analog rollout unit."},{"cited_title":"In: 2022 32nd International Confer- ence on Field-Programmable Logic and Applications (FPL), pp","cited_arxiv_id":null,"evidence_quote":"It supplies the fabricated 180-nm CMOS RRAM crossbar whose timing and device parameters are scaled to 22 nm."},{"cited_title":"Available online (2022)","cited_arxiv_id":null,"evidence_quote":"It provides the cycle-accurate discrete-event simulation framework that produces the reported energy, power, and latency numbers."},{"cited_title":"In: 2022 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp","cited_arxiv_id":null,"evidence_quote":"It is the open-source MCTS engine used for the iso-compute comparison of playing strength."},{"cited_title":"In: Latifi, S","cited_arxiv_id":null,"evidence_quote":"It is the second open-source MCTS engine used for the same iso-compute strength comparison."},{"cited_title":"In: Proceedings of the 41st International Conference on Machine Learning (ICML)","cited_arxiv_id":null,"evidence_quote":"It supplies the technology scaling equations used to convert synthesized 65-nm results to 22 nm."}],"review_version":2}