McDRAM: Low Latency and Energy-Efficient Matrix Computations in DRAM

Shin, Hyunsung; Kim, Dong‐Young; Park, Eunhyeok; Park, Sungho; Park, Yong-Sik; Yoo, Sungjoo

doi:10.1109/tcad.2018.2857044

Cited by 65 publications

(66 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We synthesized both the NDR and IDR units using the Synopsys Design Compiler with 40nm CMOS technology at a frequency of 300 and 200 MHz and scaled the result of IDR to a 20nm DRAM process referring to [5], [12]. The total area overhead of IDRs is 0.903 mm 2 per DRAM chip, assuming that each chip has ×8 data I/O bit-width.…”

Section: Design Overheadmentioning

confidence: 99%

TRiM: Tensor Reduction in Memory

Kim

Park

Lee

et al. 2021

IEEE Comput. Arch. Lett.

View full text Add to dashboard Cite

Section: Design Overheadmentioning

confidence: 99%

TRiM: Tensor Reduction in Memory

Kim

Park

Lee

et al. 2021

IEEE Comput. Arch. Lett.

View full text Add to dashboard Cite

“…If a memory controller receives the standard DRAM memory requests while a PIM operation is in progress, the controller should service the requests as soon as possible to satisfy their performance requirement. However, the previous PIM research did not provide the solutions, and instead, the standard memory requests are assumed to be not received when the PIM operation is in progress [19], [21]- [23], [42]. However, their cooperation should be studied.…”

Section: B Cooperating With Standard Memory Requestsmentioning

confidence: 99%

“…One of the most critical issues in implementing PIM is the area overhead of MAC ALUs. McDRAM [42] analyzed the overhead when designing MAC ALUs for BLSAs, column decoders, and I/O drivers in DRAM. Also, [42] showed that the design of 256 8-bit MACs at the column decoder positions incurs the area overhead of about 4.7% of the total DRAM area.…”

Section: Pim Datapath and Commandsmentioning

confidence: 99%

“…McDRAM [42] analyzed the overhead when designing MAC ALUs for BLSAs, column decoders, and I/O drivers in DRAM. Also, [42] showed that the design of 256 8-bit MACs at the column decoder positions incurs the area overhead of about 4.7% of the total DRAM area. Because McDRAM and we used the same MAC configuration, both methods would suffer from similar area overhead.…”

Section: Pim Datapath and Commandsmentioning

confidence: 99%

“…Most previous PIM studies have focused on designing the application-specific accelerators in the logic die of the 3D-stacked memory, such as HMC [39] or HBM/HBM2 [40], [41], and few studies have implemented the accelerator within DRAM [42]. However, all of them assumed that they did not service the standard DRAM requests during their computation even though handling a standard memory request during the PIM operation is essential for PIM to act as both a memory and an accelerator.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Design of Processing-“Inside”-Memory Optimized for DRAM Behaviors

et al. 2019

View full text Add to dashboard Cite

The computing domain of today's computer systems is moving very fast from arithmetic to data processing as data volumes grow exponentially. As a result, processing-in-memory (PIM) studies have been actively conducted to support the data processing in or near memory devices to address the limited bandwidth and high power consumption due to data movement between CPU/GPU and memory. However, most PIM studies so far have been conducted in a way that the processing units are designed only as an accelerator on the base die of 3D-stacked DRAM, not involved inside memory while not servicing the standard DRAM requests during the PIM execution. Therefore, in this paper, we show how to design and operate the PIM computing units inside DRAM by effectively coordinating with standard DRAM operations while achieving the full computing performance and minimizing the implementation cost. To make our goals, we extend a standard DRAM state diagram to depict the PIM behaviors in the same way as standard DRAM commands are scheduled and operated on the DRAM devices and exploit several levels of parallelism to overlap memory and computing operations. Also, we present how the entire architecture layers from applications to operating systems, memory controllers, and PIM devices should work together for the effective execution by applying our approaches to our experiment platform. In our HBM2-based experimental platform to include 16-cycle MAC (Multiply-and-Add) units and 8-cycle reducers for a matrix-vector multiplication, we achieved 406% and 35.2% faster performance by the all-bank and the per-bank schedulings, respectively, at (1024 × 1024) × (1024 × 1) 8-bit integer matrix-vector multiplication than the execution of only its operand burst reads assuming the external full DRAM bandwidth. It should be noted that the performance of the PIM on a base die of a 3D-stacked memory cannot be better than that provided by the full bandwidth in any case.

show abstract