Seminars
Starting in Week 3, one student presents a short seminar every week: 15 minutes presentation + 5 minutes Q&A, on a paper related to that week's block (see Calendar). Spreading seminars across the whole semester - instead of concentrating them near the end - keeps the weekly workload manageable and lets each seminar connect to what the class is building at that time.
How it works
- Each student picks (or is assigned) one paper per topic bucket below, related to the block being covered that week.
- The presentation should cover: the problem being addressed, the proposed approach, and - most importantly - how it relates to what we are building in this course (e.g., "this is a more sophisticated version of the bus we designed in Project 2").
- The schedule (who presents when, and on which paper) will be filled in once class size is known - see the table at the bottom of this page.
Topic buckets
Weeks 3-6: RISC-V and microarchitecture
Papers on RISC-V core implementations, microarchitecture techniques (pipelining, branch prediction, etc.), and open-source processor design. Example seed topics:
- Open-source RISC-V core designs (e.g., Rocket, Ibex, PicoRV32) and their design trade-offs.
- Microarchitectural techniques for small/embedded cores.
- Verification methodologies for open hardware.
Ethics/society angle (pick one of these instead of a technical paper if interested):
- Open ISA vs proprietary: the impact of RISC-V on competition, access, and sovereignty — who benefits when an ISA is free? (e.g., RISC-V adoption in China/India vs Arm licensing model.)
- Hardware supply chain trust: who verifies that a commercial chip does what it claims? The case for open-source silicon and reproducible hardware builds.
- E-waste and planned obsolescence: how proprietary hardware locks contribute to electronic waste — does open hardware change the equation?
Weeks 7-9: Hardware/software interfaces
Papers on hardware/software codesign, on-chip buses, memory-mapped peripherals, and custom-instruction extensions. Example seed topics:
- Hardware/software partitioning and codesign methodologies.
- On-chip bus standards and their trade-offs (Wishbone, AXI, TileLink, ...).
- Custom-instruction / coprocessor interfaces in embedded processors.
Ethics/society angle:
- UART and physical access: the ethics of hardware debug interfaces — when is a debug port a feature vs a vulnerability? Cases from IoT devices, medical equipment, and voting machines.
- Secure boot and user freedom: the tension between secure boot (preventing unauthorized code) and user autonomy (right to repair, right to run your own software). Examples: John Deere tractors, game consoles, smartphones.
- Embedded systems in critical infrastructure: who is liable when a firmware bug in a power grid controller, a medical device, or an automotive ECU causes harm?
Weeks 10-15: AI accelerators and TinyML
Papers on TinyML, edge inference, and hardware accelerators for neural networks. Example seed topics:
- TinyML frameworks and deployment on microcontroller-class devices.
- Hardware accelerators for quantized (int8) neural network inference.
- Hardware/software codesign case studies for ML acceleration (e.g., CNN accelerators on FPGAs).
- Alternative points in the design space: vector ISA extensions (e.g., RISC-V "V"), dedicated NPUs (e.g., Arm Ethos-U), unified-memory accelerator architectures, or roofline/memory-bottleneck analyses of ML inference.
Ethics/society angle:
- Always-on listening: KWS devices (Alexa, Google Home) are designed to listen continuously. What are the privacy implications? Review a case study (e.g., Amazon Echo recordings subpoenaed as evidence, 2016).
- Bias in speech recognition: Google Speech Commands v2 is predominantly American English. How does this affect accuracy for non-native speakers, regional accents, or underrepresented languages? What does it mean to deploy biased models at scale on cheap hardware?
- Surveillance at the edge: the same TinyML hardware that enables a voice assistant in a hearing aid can enable mass audio surveillance in public spaces. Who decides what models run on deployed edge devices? Can they be updated silently?
- Environmental cost of ML training vs inference: training a large model once can emit as much CO₂ as five cars over their lifetime (Strubell et al., 2019). But edge inference is extremely efficient (~0.5 mJ). How does the full lifecycle energy balance compare?
- Accountability in autonomous decisions: when a TinyML classifier on an industrial sensor triggers a safety shutdown (or fails to), who is responsible — the model designer, the hardware engineer, the deployer, or the end user?
Schedule
| Week | Student | Paper | Bucket |
|---|---|---|---|
| 3 | TBD | TBD | RISC-V / microarchitecture |
| 4 | TBD | TBD | RISC-V / microarchitecture |
| 5 | TBD | TBD | RISC-V / microarchitecture |
| 6 | TBD | TBD | RISC-V / microarchitecture |
| 7 | TBD | TBD | HW/SW interfaces |
| 8 | TBD | TBD | HW/SW interfaces |
| 9 | TBD | TBD | HW/SW interfaces |
| 10 | TBD | TBD | AI accelerators / TinyML |
| 11 | TBD | TBD | AI accelerators / TinyML |
| 12 | TBD | TBD | AI accelerators / TinyML |
| 13 | TBD | TBD | AI accelerators / TinyML |
| 14 | TBD | TBD | AI accelerators / TinyML |