Pith. sign in

REVIEW 3 major objections 5 minor 25 references

A Software-based NVM Emulator Supporting Read/Write Asymmetric Latencies

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

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

Pith's one-line read A DRAM-based emulator estimates NVM program performance by tracking write-back cache misses, reproducing 200–1000 ns write latencies within 1.1% error.

desk verdict Honest extension of the authors' own 2017 emulator; the accuracy claim is solid only for a microbenchmark that bypasses the key write-back attribution assumption, so the workload-level results are suggestive, not proven. read the letter →

arxiv 1908.02135 v1 pith:OOTYWQJX submitted 2019-08-02 cs.DC

Atsushi Koshiba , Takahiro Hirofuchi , Ryousei Takano , Mitaro Namiki This is my paper · ORCID
classification cs.DC
keywords NVMemulationwrite-backawarenessasymmetricread/writelatenciesperformanceemulatorlast-levelcachemissesnon-volatilememoryhardwarecounters
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 claims that the performance of software on future non-volatile main memory can be estimated on today's DRAM machines by a lightweight emulator that inserts extra delays where slower NVM writes would stall the CPU. Existing lightweight software emulators ignore the read/write latency gap, and cycle-accurate simulators are too slow for realistic workloads. The proposed model splits last-level-cache misses into read-only misses and write-back misses, estimating per process how many write-backs each core caused by combining core performance counters with an LLC-controller counter. On an Intel Xeon prototype it emulated NVM write latencies from 200 ns to 1000 ns with errors between 0.2% and 1.1%, and in a Memcached case study it produced throughput estimates that an existing latency-blind emulator misestimated. If this is right, system software researchers gain an accurate, fast tool for exploring NVM-optimized designs before NVM hardware is widely available.

What carries the argument

The central object is Eq. (9), a proportionality estimate for per-process write-back last-level-cache misses: $L LC^\mathrm{WB}_{miss} = WB \times L LC_{miss} / (\sum_i L LC_{miss,\mathrm{cpu}_i} + \sum_i L LC_{miss,\mathrm{PF}_i})$. Here $WB$ is the total number of write-back operations measured by an uncore cache-controller (CBo) counter, and the denominator sums LLC misses from all CPU cores and all prefetchers. This equation supplies the per-process write-back count that CPU core counters cannot provide directly, feeding the delay formula that distinguishes write-back from read-only misses. The working assumption is that write-backs are distributed across processes in proportion to their LLC misses, which is the premise on which the whole emulation model rests.

What would settle it

Run a two-thread test where one thread repeatedly writes a few hot cache lines (few LLC misses) while the other streams a large array (many misses); Eq. (9) will attribute most write-backs to the streaming thread even though the writer owns the dirty lines. A cycle-accurate simulation, or a CPU that exposes per-core write-back counts, would reveal that the attribution is wrong.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a write-back aware emulation model reproduces the asymmetric read/write latencies of NVM-based main memory on an ordinary DRAM machine, with negligible error for write latencies between 200 ns and 1000 ns. The model computes the inserted delay per epoch as $M A^{WB}_i \times (NVM^\mathrm{write}_{lat} - DRAM_{lat}) + M A^{RO}_i \times (NVM^\mathrm{read}_{lat} - DRAM_{lat})$, where the two miss counts are read-only and write-back last-level-cache misses that actually stall the CPU. The load-bearing estimate is Eq. (9): a process's write-back LLC misses equal the system-wide write-back count from an uncore cache-controller counter, scaled by the process's share of all LLC misses (core-induced plus prefetcher-induced). The prototype, implemented for a server processor of the Haswell family, validates the model with microbenchmarks (wbbench and robench), with 28 SPECCPU 2006 workloads where write-intensive benchmarks slow by nearly 2x at a 1000 ns write latency, and with Memcached, where the latency-blind emulator misestimates throughput while the write-back aware model tracks it. The paper also reports the emulator runs about three orders of magnitude faster than a cycle-accurate memory simulator paired with a full-system CPU simulator.

Load-bearing premise

The load-bearing premise is that a process's write-back last-level-cache misses equal its share of all LLC misses; this assumes write-backs spread proportionally to miss counts, ignoring dirty-line ownership and prefetcher evictions of modified lines, and the microbenchmark validation never stresses this assumption because every miss there causes a write-back.

Editorial extensions

If this is right

  • Researchers can evaluate NVM-optimized operating systems and applications on ordinary DRAM servers, at single-threaded accuracy sufficient to identify write-sensitive workloads.
  • Write-intensive SPECCPU workloads such as milc, GemsFDTD, and libquantum show nearly 2x slowdown at a 1000 ns write latency, giving a concrete screening target for NVM-aware optimization.
  • Because the model distinguishes read-only from write-back misses, it captures the effect of prefetchers and memory-level parallelism, explaining why some write-heavy benchmarks are less sensitive to high write latency.
  • Latency-blind emulators under-estimate the impact of asymmetric NVM: the Memcached case shows throughput differs substantially when only the write latency is raised.
  • The same read-versus-write classification suggests the emulator can be extended to model the energy asymmetry of NVM, as the paper notes.

Reading between the lines

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

  • If Eq. (9)'s proportionality is applied to multi-threaded workloads, cache-contention changes from suspension and dirty-line placement will shift the write-back attribution; a dirty-line-ownership counter would be the natural fix.
  • The reported error bounds hold when the read latency stays at DRAM latency; emulating a slower NVM read latency, or varying both latencies together, remains untested and is a straightforward extension.
  • The write-queue behavior of the NVM controller is not modeled, so under heavily write-saturated multiprogramming the inserted delays may either over- or under-estimate the true stall time; adding a queue model is a testable extension.
  • A stronger validation of Eq. (9) would compare its per-process write-back estimates against hardware that exposes per-core write-back events, or against a cycle-accurate cache model, rather than only against whole-program execution times.
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 / 5 minor

Summary. The paper presents a software-based emulator for NVM main memory with asymmetric read/write latencies. The emulator runs the target workload on DRAM, periodically reads CPU-core and LLC-controller performance counters, classifies LLC misses into read-only and write-back misses, and injects delays into the target process. The per-process write-back count is estimated by assuming proportionality to the process's share of all LLC misses (Eq. 9). A prototype is implemented for Intel Haswell processors. Accuracy is assessed with two microbenchmarks (wbbench and robench), and case studies are run for SPECCPU 2006 and Memcached, where the proposed emulator is compared with Quartz. The paper reports write-latency emulation errors of 0.1% to 1.1% and argues that the write-back-aware model outperforms Quartz for realistic workloads.

Significance. If the central claims held, the emulator would be a practical lightweight tool for NVM software research, filling a gap left by Quartz's inability to distinguish read and write latencies. The microbenchmark calibration in Table 3 is careful, and the reported overhead advantage over NVMain+gem5 in Table 5 is real. However, the accuracy validation is currently limited to a microbenchmark in which every LLC miss is a write-back, and the workload-level experiments lack any external ground truth. The significance for practical workloads therefore remains unestablished until Eq. (9) is validated and the SPEC/Memcached results are checked against a reference.

major comments (3)
  1. [§3.2 (Eq. 9); §4.1–4.2 (Fig. 6, Table 4)] The core per-process write-back estimation, Eq. (9), is not validated: it assumes that a process's write-back LLC misses equal the system-wide write-back count multiplied by the process's share of all LLC misses. In the wbbench validation (§4.1, Fig. 6), every pointer-chasing iteration modifies the current line and then misses on the next line, so every LLC miss evicts a modified line; consequently WB equals the process's miss count and Eq. (9) reduces to an identity. Table 4 therefore validates only the delay-injection mechanism, not the proportionality assumption. For realistic workloads, dirty-line ownership, prefetcher evictions, and cross-core evictions can break this proportionality, and the SPEC/Memcached experiments provide no check on it. The workload-level accuracy claim in §4.3 and §4.4 is thus unsupported at the load-bearing step.
  2. [§4.3 (Figs. 7–10); §4.4 (Figs. 11–14); §6] The SPECCPU 2006 and Memcached evaluations lack a ground-truth reference. The paper compares the proposed emulator only with Quartz, which is itself an approximate emulator, and with the no-emulation baseline. Without a comparison against real NVM hardware, a validated cycle-accurate simulator (the authors run NVMain+gem5 in §4.3, but only to measure runtime, not to validate accuracy), or an FPGA-based emulator, the claim that the proposed emulator 'successfully estimated the execution time' of these workloads is not demonstrated. The final section's statement that future work will 'evaluate the accuracy of the proposed mechanism using actual NVM devices' confirms that this validation is still missing.
  3. [§3.1 (Eq. 5); §4.3] The delay model in Eq. (5) adds the full (NVM_write − DRAM) penalty for every estimated write-back miss, but the derivation of the miss counts in Eqs. (7)–(8) scales the observed L2 stall cycles by miss-count proportions. When memory-level parallelism and write buffering allow NVM writes to overlap with other accesses, the additive per-miss penalty may not equal the true additional stall time, and the serial pointer-chasing wbbench workload cannot exercise this regime. The paper's claim in §4.3 that the emulator is 'effective to estimate the performance impact of memory-level parallelism' is therefore not supported by the experiments presented.
minor comments (5)
  1. [§4.2] The text after Table 4 contains a typo: 'wbbehcn' should be 'wbbench'.
  2. [Fig. 9 caption] The caption uses 'Propotion' instead of 'Proportion'; please correct the spelling.
  3. [§3.2, Eq. (9)] The numerator L_LCmiss in Eq. (9) is not defined with a subscript; clarify explicitly that it is the target process's LLC miss count, not the system-wide total.
  4. [§2.3 and Fig. 3] The notation 'Epoch' appears as 'E poch' in several places (e.g., Fig. 3 and Eqs. (1)–(2)); unify the formatting for readability.
  5. [§4.4, footnote 1] The single-threaded limitation disclosed in the footnote should be stated earlier in the paper, since it directly bounds the generality of the Memcached case study and the overall claims.

Circularity Check

1 steps flagged · score 4.0 of 10

The wbbench accuracy test is self-consistent by construction: with every LLC miss also a write-back and no prefetcher traffic, Eq. (9) degenerates to a 1:1 ratio, so the measured write latency is the configured delay; Eq. (9)'s attribution is not independently validated by workload-level ground truth.

  1. self definitional [Section 4.1-4.2 (wbbench design and Table 4); Eq. (9) in Section 3.2]
    "To ensure that every get_nextline_from_list() call induces an LLC miss, we set the size of the memory region reserved by wbbench/robench to 30 MB, which is twice as large as the LLC size of our environment (15 MB). ... When applying our emulator to wbbench, the NVM write latencies were emulated with errors of 0.1% to 1.1%."

    In wbbench, each loop iteration writes to a cache line and then follows a random pointer to the next line, so every LLC miss evicts a modified line and induces a write-back; random accesses suppress prefetching and out-of-order execution. Under these conditions, the target process's LLC miss count equals the system-wide write-back count and the denominator of Eq. (9) equals its numerator, so the estimated L LCW B_miss is identically the measured miss count. Eq. (5) then injects exactly (NVM_write - DRAM) per such miss. The wbbench 'measured' latency is loop time divided by line count, which therefore returns the configured write latency up to hardware-counter error by construction. This validates the delay-injection loop, but it cannot test Eq.

full rationale

The model itself is not derived from the results it claims to predict: Eq. (9) is an openly stated proportional-attribution assumption, and the delay formula Eq. (5) is a transparent construction rather than a fitted model. There is no load-bearing self-citation chain; the NVMSA 2017 self-citation concerns reimplementation and portability, not the validity of the core equation. The significant weakness is that the headline accuracy evidence is circular in a narrow but important sense: the wbbench microbenchmark is deliberately constructed so that every miss is a write-back and no prefetcher misses occur, making Eq. (9)'s estimated per-process write-back count equal to the observed miss count. Thus Table 4 demonstrates that the emulator can inject the configured delay into a workload that trivially satisfies its assumptions, not that Eq. (9) correctly attributes write-backs in realistic multi-cause workloads. The later SPEC and Memcached experiments are model outputs with no external reference measurement, so the claim that the emulator 'successfully estimate[s] performance of practical workloads' is not independently corroborated. This is a partial circularity in validation rather than a fully circular derivation, so the score is moderate rather than extreme.

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

The central derivation relies on a small set of hardware measurements (DRAM_lat, W) and the proportional write-back allocation assumption in Eq. (9). No new physical entities are introduced. The main unvalidated load-bearing assumption is the proportionality of write-backs to LLC miss share.

free parameters (1)
  • Epoch = 20 ms
    The emulator suspends and resumes the target process at fixed Epoch intervals; 20 ms was chosen by hand after observing it balanced accuracy and overhead (Sec. 4). It is a tunable parameter, not fitted to the target NVM latencies.
assumptions (4)
  • domain assumption Last-level cache misses can be cleanly divided into read-only and write-back misses, and write-back misses cause longer CPU stalls on NVM.
    This is the core behavioral model in Sec. 2.1-2.2 and Eq. (5). It assumes write-backs are not hidden behind reads for NVM, which is plausible but not validated against real NVM hardware.
  • ad hoc to paper Per-process write-backs are proportional to the process's share of system-wide LLC misses (Eq. 9).
    Eq. 9 allocates system-wide write-back counts to the target process by its LLC miss ratio. This is an assumption introduced for this paper and is not independently validated.
  • domain assumption The Intel performance counter formulas (Eq. 3 from Intel documentation) correctly estimate stall cycles caused by LLC misses.
    The model relies on Intel's optimization manual equation to convert L2 stall cycles into LLC miss counts; this is a vendor-derived approximation.
  • domain assumption NVM is byte-addressable and write-back cacheable like DRAM.
    Stated in Sec. 2.1; the emulation targets this memory model.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Software-based NVM Emulator Supporting Read/Write Asymmetric Latencies." pith.science (2026). https://pith.science/paper/OOTYWQJX

@misc{pith2026190802135,
  author       = {Pith},
  title        = {Pith review of: A Software-based NVM Emulator Supporting Read/Write Asymmetric Latencies},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OOTYWQJX}},
  note         = {Machine review of arXiv:1908.02135}
}
read the original abstract

Non-volatile memory (NVM) is a promising technology for low-energy and high-capacity main memory of computers. The characteristics of NVM devices, however, tend to be fundamentally different from those of DRAM (i.e., the memory device currently used for main memory), because of differences in principles of memory cells. Typically, the write latency of an NVM device such as PCM and ReRAM is much higher than its read latency. The asymmetry in read/write latencies likely affects the performance of applications significantly. For analyzing behavior of applications running on NVM-based main memory, most researchers use software-based emulation tools due to the limited number of commercial NVM products. However, these existing emulation tools are too slow to emulate a large-scale, realistic workload or too simplistic to investigate the details of application behavior on NVM with asymmetric read/write latencies. This paper therefore proposes a new NVM emulation mechanism that is not only light-weight but also aware of a read/write latency gap in NVM-based main memory. We implemented the prototype of the proposed mechanism for the Intel CPU processors of the Haswell architecture. We also evaluated its accuracy and performed case studies for practical benchmarks. The results showed that our prototype accurately emulated write-latencies of NVM-based main memory: it emulated the NVM write latencies in a range from 200 ns to 1000 ns with negligible errors from 0.2% to 1.1%. We confirmed that the use of our emulator enabled us to successfully estimate performance of practical workloads for NVM-based main memory, while an existing light-weight emulation model misestimated.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages

  1. [1]

    Raidr: Retention-awarein- telligentdramrefresh,

    J.Liu,B.Jaiyen,R.Veras,andO.Mutlu,“Raidr: Retention-awarein- telligentdramrefresh,”Proceedingsofthe39thAnnualInternational SymposiumonComputerArchitecture,ISCA’12,Washington,DC, USA, pp.1–12, IEEE Computer Society, 2012

    work page 2012

  2. [2]

    Energy management for commercial servers,

    C.Lefurgy, K.Rajamani, F.Rawson, W.Felter, M.Kistler, andT.W. Keller, “Energy management for commercial servers,” Computer, vol.36, no.12, pp.39–48, Dec 2003

    work page 2003

  3. [3]

    International technology roadmap for semiconduc- tors 2013 edition

    ITRS, “International technology roadmap for semiconduc- tors 2013 edition.” http://www.semiconductors.org/clientuploads/ Research_Technology/ITRS/2013/2013PIDS.pdf, 2013

    work page 2013

  4. [4]

    Intel®optane™ ssd dc p4800x series

    Intel, “Intel®optane™ ssd dc p4800x series.” http://www.intel.com/ content/www/us/en/solid-state-drives/optane-solid-state-drives-dc- p4800x-series.html, 2017

    work page 2017

  5. [5]

    Towardswrite-backawaresoftwareemulatorfornon-volatilemem- ory,

    A. Koshiba, T. Hirofuchi, S. Akiyama, R. Takano, and M. Namiki, “Towardswrite-backawaresoftwareemulatorfornon-volatilemem- ory,”2017IEEE6thNon-VolatileMemorySystemsandApplications Symposium (NVMSA), pp.1–6, Aug 2017

    work page 2017

  6. [6]

    Phasechange memory technology,

    G.W. Burr, M.J. Breitwisch, M. Franceschini, D. Garetto, K. Gopalakrishnan, B. Jackson, B. Kurdi, C. Lam, L.A. Lastras, A.Padilla,B.Rajendran,S.Raoux,andR.S.Shenoy,“Phasechange memory technology,” Journal of Vacuum Science & Technology B, Nanotechnology and Microelectronics: Materials, Processing, Mea- surement, and Phenomena, vol.28, no.2, pp.223–262, 2010

    work page 2010

  7. [7]

    Soft2lm: Application guided heterogeneousmemorymanagement,

    M. Giardino, K. Doshi, and B. Ferri, “Soft2lm: Application guided heterogeneousmemorymanagement,”2016IEEEInternationalCon- ference on Networking, Architecture and Storage (NAS), pp.1–10, Aug 2016

    work page 2016

  8. [8]

    System software for persistent mem- ory,

    S.R. Dulloor, S. Kumar, A. Keshavamurthy, P. Lantz, D. Reddy, R. Sankaran, and J. Jackson, “System software for persistent mem- ory,” Proceedings of the Ninth European Conference on Computer Systems, EuroSys ’14, New York, NY, USA, pp.15:1–15:15, ACM, 2014

    work page 2014

Show all 25 references
  1. [9]

    Better i/o through byte-addressable, persistent mem- ory,

    J.Condit,E.B.Nightingale,C.Frost,E.Ipek,B.Lee,D.Burger,and D. Coetzee, “Better i/o through byte-addressable, persistent mem- ory,” Proceedings of the ACM SIGOPS 22Nd Symposium on Oper- ating Systems Principles, SOSP ’09, New York, NY, USA, pp.133– 146, ACM, 2009

    2009

  2. [10]

    Nvmain: Anarchitectural-levelmainmem- orysimulatorforemergingnon-volatilememories,

    M.PorembaandY.Xie,“Nvmain: Anarchitectural-levelmainmem- orysimulatorforemergingnon-volatilememories,”2012IEEECom- puter Society Annual Symposium on VLSI, pp.392–397, Aug 2012

    2012

  3. [11]

    Hmmsim: a simulatorforhardware-softwareco-designofhybridmainmemory,

    S. Bock, B.R. Childers, R. Melhem, and D. Mosse, “Hmmsim: a simulatorforhardware-softwareco-designofhybridmainmemory,” 2015 IEEE Non-Volatile Memory System and Applications Sympo- sium (NVMSA), pp.1–6, Aug 2015

    2015

  4. [12]

    Quartz: A lightweight performance emulator for persistent memory software,

    H. Volos, G. Magalhaes, L. Cherkasova, and J. Li, “Quartz: A lightweight performance emulator for persistent memory software,” Proceedingsofthe16thAnnualMiddlewareConference,Middleware ’15, New York, NY, USA, pp.37–49, ACM, 2015

    2015

  5. [13]

    Intel 64 and ia-32 architectures optimization refer- ence manual

    Intel, “Intel 64 and ia-32 architectures optimization refer- ence manual.” http://www.intel.com/content/dam/www/public/us/ en/documents/manuals/64-ia-32-architectures-optimization-manual .pdf

  6. [14]

    Nvsim: A circuit-level performance,energy,andareamodelforemergingnonvolatilemem- ory,

    X. Dong, C. Xu, Y. Xie, and N.P. Jouppi, “Nvsim: A circuit-level performance,energy,andareamodelforemergingnonvolatilemem- ory,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol.31, no.7, pp.994–1007, July 2012

    2012

  7. [15]

    The gem5 simulator,

    N. Binkert, B. Beckmann, G. Black, S.K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D.R. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. Shoaib, N. Vaish, M.D. Hill, and D.A. Wood, “The gem5 simulator,” SIGARCH Comput. Archit. News, vol.39, no.2, pp.1–7, Aug. 2011

    2011

  8. [16]

    Intel xeon processor e5 v3 family uncore performance moni- toring

    Intel, “Intel xeon processor e5 v3 family uncore performance moni- toring.”https://www.intel.com/content/www/us/en/processors/xeon/ xeon-e5-v3-uncore-performance-monitoring.html

  9. [17]

    Intel 64 and ia-32 architectures software devel- oper’smanual

    Intel, “Intel 64 and ia-32 architectures software devel- oper’smanual.”http://www.intel.in/content/dam/www/public/us/en/ documents/manuals/64-ia-32-architectures-software-developer-man ual-325462.pdf

  10. [18]

    Intel memory latency checker

    V. Viswanathan, “Intel memory latency checker.” https:// software.intel.com/en-us/articles/intelr-memory-latency-checker

  11. [19]

    Dramsim2: A cycle accurate memory system simulator,

    P. Rosenfeld, E. Cooper-Balis, and B. Jacob, “Dramsim2: A cycle accurate memory system simulator,” IEEE Computer Architecture Letters, vol.10, no.1, pp.16–19, Jan 2011

    2011

  12. [20]

    Marss: A full system simulator for multicore x86 cpus,

    A. Patel, F. Afram, S. Chen, and K. Ghose, “Marss: A full system simulator for multicore x86 cpus,” Proceedings of the 48th Design Automation Conference, DAC ’11, New York, NY, USA, pp.1050– 1055, ACM, 2011. 12 IEICE TRANS. INF. & SYST., VOL.E102-D, NO.12 DECEMBER 2019

    2011

  13. [21]

    Fpga-basedprototyping systems for emerging memory technologies,

    T.Lee,D.Kim,H.Park,S.Yoo,andS.Lee,“Fpga-basedprototyping systems for emerging memory technologies,” 2014 25nd IEEE In- ternational Symposium on Rapid System Prototyping, pp.115–120, Oct 2014

    2014

  14. [22]

    Building emulation frame- work for non-volatile memory,

    G. Zhu, K. Lu, X. Wang, and Y. Dong, “Building emulation frame- work for non-volatile memory,” 2017 IEEE 37th International Con- ference on Distributed Computing Systems Workshops (ICDCSW), pp.330–333, June 2017

    2017

  15. [23]

    A framework for emulating non-volatile memory systemswith different performance characteristics,

    D.Sengupta,Q.Wang,H.Volos,L.Cherkasova,J.Li,G.Magalhaes, and K. Schwan, “A framework for emulating non-volatile memory systemswith different performance characteristics,” Proceedings of the 6th ACM/SPEC International Conference on Performance Engi- neering, ICPE ’15, New York, ...

    2015

  16. [24]

    Greengovernors: A frameworkforcontinuouslyadaptivedvfs,

    V.Spiliopoulos,S.Kaxiras,andG.Keramidas,“Greengovernors: A frameworkforcontinuouslyadaptivedvfs,”2011InternationalGreen Computing Conference and Workshops, pp.1–8, July 2011

    2011

  17. [25]

    Hme: A lightweight emu- lator for hybrid memory,

    Z. Duan, H. Liu, X. Liao, and H. Jin, “Hme: A lightweight emu- lator for hybrid memory,” 2018 Design, Automation Test in Europe Conference Exhibition (DATE), pp.1375–1380, March 2018. Atsushi Koshiba is a Ph.D. student in the Department of Electric and Information Sciences at ...

    2018

Pith tools

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