Personal tools

An RPC DRAM Implementation for Energy-Efficient ASICs (1-2S)

From iis-projects

Revision as of 18:36, 15 February 2021 by Paulsc (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Overview

Status: Available

Character

  • 10% Research
  • 50% Implementation / Verification
  • 20% Synthesis and Backend
  • 20% Tapeout

Prerequisites

  • 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

Introduction

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)  [1] memories only require a simple on-chip PHY and can operate with regular digital IO pads making them usable on our ASICs.


caption RPC DRAM Chips: there are currently three different packaging options, including WLCSP, available

[fig:rpc_dram]

Project Description

The core goal of the project is to implement a simple RPC DRAM interface on an ASIC and tape it out.

Milestones

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  [2] .
  • Draft an architecture for your RPC DRAM controller:
    • Gather inspiration from our HyperBus  [3] memory controller and the Antmicro RPC DRAM FPGA reference implementation  [4] .
    • Handle the core tasks with dedicated hardware whenever applicable and handle the higher-level tasks (like DRAM refresh) in firmware on a dedicated RISC-V processor  [5] .
  • 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.

Stretch Goals

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.

Project Realization

Time Schedule

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
Proposed time schedule and investment

Meetings

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.

Weekly Reports

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.

HDL Guidelines

Naming Conventions

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/.

Report

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.

Final Report

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.

Presentation

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.

Deliverables

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

References

[1] “Etron Technology Inc. RPC DRAM.” https://etronamerica.com/products/rpc-dram/.

[2] Etron Technology Inc., “256Mb High Bandwidth RPC DRAM (Advance Revision 1.7).”.

[3] “bslk / hyperbus IIS GitLab.” https://iis-git.ee.ethz.ch/bslk/hyperbus.

[4] “antmicro / litedram GitHub.” https://github.com/antmicro/litedram/tree/rpc-dram-support.

[5] 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.