An RPC DRAM Implementation for Energy-Efficient ASICs (1-2S)
- 1 Overview
- 2 Introduction
- 3 Project Description
- 4 Milestones
- 5 Project Realization
- 6 Deliverables
- 7 References
- Type: ASIC Semester Thesis
- Professor: Prof. Dr. L. Benini
- Students: Jinfan Chen, Rui Zhou
- 10% Research
- 50% Implementation / Verification
- 20% Synthesis and Backend
- 20% Tapeout
- Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I
- Must have visit VLSI2 in a previous semester or take it alongside the thesis
At IIS, we are constantly facing a tradeoff when working on ASICs: our applications increasingly require more memory, but we only have little silicon area available for on-chip memory. Using off-chip memory alleviates this discrepancy by providing large capacities. Typically, when using off-chip memories, we face a completely different problems than in common, on-chip digital design. Off-chip memories require:
- A complex physical layer (PHY) on the ASIC, often featuring analog blocks like PLLs.
- Specialized pads for low-voltage differential signaling.
- Many IO channels to transfer commands, addresses, and data signals.
- A large and complex memory controller managing memory accesses and refreshes.
These requirements prevent us from implementing traditional off-chip memory solutions, like DDR3 or DDR4, on our ASICs.
Recently, a new class of off-chip memories hit the market, targeting low area and low pin-count FPGAs and ASICs. These reduced pin count DDR (RPC DDR)  memories only require a simple on-chip PHY and can operate with regular digital IO pads making them usable on our ASICs.
The core goal of the project is to implement a simple RPC DRAM interface on an ASIC and tape it out.
The following are the milestones that we expect to achieve throughout the project:
- Get to know the protocol by reading the Etron Technology RPC DRAM data sheet  .
- Draft an architecture for your RPC DRAM controller:
- Verify your implementation in simulation.
- Synthesize your controller and the surrounding system; create area and timing reports.
- Implement your system on an ASIC and tape it out.
Should the above milestones be reached earlier than expected and you are motivated to do further work, we propose the following stretch goals to aim for:
- Demonstrate your implementation on an FPGA.
- Optimize the memory controller to increase throughput, utilization, and/or use intelligent refresh strategies.
- Expand the SoC to allow more complex applications to run on your chip.
The time schedule presented in [tab:time_plan] is merely a proposition; it is primarily intended as a reference and an estimation of the time required for each required step.
|Project phase||Time estimate|
|Read and understand RPC DRAM specification||1 week|
|Draft, implement, and verify controller||5 weeks|
|Synthesize controller and system||2 weeks|
|Implement ASIC: backend, DRC, LVS, PLS||3 weeks|
|Stretch goals||remaining time|
|Write report||1 week|
|Prepare presentation||1 week|
Weekly meetings will be held between the student and the assistants. The exact time and location of these meetings will be determined within the first week of the project in order to fit the student’s and the assistants’ schedule. These meetings will be used to evaluate the status and progress of the project. Beside these regular meetings, additional meetings can be organized to address urgent issues as well.
The student is advised, but not required, to a write a weekly report at the end of each week and to send it to his advisors. The idea of the weekly report is to briefly summarize the work, progress and any findings made during the week, to plan the actions for the next week, and to bring up open questions and points. The weekly report is also an important means for the student to get a goal-oriented attitude to work.
Adapting a consistent naming scheme is one of the most important steps in order to make your code easy to understand. If signals, processes, and entities are always named the same way, any inconsistency can be detected easier. Moreover, if a design group shares the same naming convention, all members would immediately feel at home with each others code. The naming conventions we follow in this project are at https://github.com/lowRISC/style-guides/.
Documentation is an important and often overlooked aspect of engineering. A final report has to be completed within this project.
The common language of engineering is de facto English. Therefore, the final report of the work is preferred to be written in English.
Any form of word processing software is allowed for writing the reports, nevertheless the use of LaTeX with Inkscape or any other vector drawing software (for block diagrams) is strongly encouraged by the IIS staff.
If you write the report in LaTeX, we offer an instructive, ready-to-use template, which can be forked from the Git repository at https://iis-git.ee.ethz.ch/akurth/iisreport.
The final report has to be presented at the end of the project and a digital copy needs to be handed in and remain property of the IIS. Note that this task description is part of your report and has to be attached to your final report.
There will be a presentation (15 min presentation and 5 min Q&A) at the end of this project in order to present your results to a wider audience. The exact date will be determined towards the end of the work.
In order to complete the project successfully, the following deliverables have to be submitted at the end of the work:
- Final report incl. presentation slides
- Source code and documentation for all developed software and hardware
- Testsuites (software) and testbenches (hardware)
- Synthesis and implementation scripts, results, and reports
 “Etron Technology Inc. RPC DRAM.” https://etronamerica.com/products/rpc-dram/.
 Etron Technology Inc., “256Mb High Bandwidth RPC DRAM (Advance Revision 1.7).”.
 “bslk / hyperbus IIS GitLab.” https://iis-git.ee.ethz.ch/bslk/hyperbus.
 “antmicro / litedram GitHub.” https://github.com/antmicro/litedram/tree/rpc-dram-support.
 F. Zaruba, F. Schuiki, T. Hoefler, and L. Benini, “Snitch: A 10 kGE Pseudo Dual-Issue Processor for Area and Energy Efficient Execution of Floating-Point Intensive Workloads.” 2020.