Green Computing + Design Verification
5 MCQs each. Lighter material — memorise the named effects and the UVM block diagram.
On this page
Green Computing — power vs energy
Power (Watts)
Instantaneous rate of energy use. Sets thermal & supply limits.
P_dynamic ∝ ½ · C · V² · f
P_static ∝ I_leak · V
Energy (Joules)
Power × time. The real cost of running a workload.
Lowering frequency cuts P but may not cut E — the task just takes longer.
Analogy
Power is how fast you're drinking from a hose. Energy is the total volume of water you swallowed. Halving the flow doesn't help if you drink twice as long.
The dynamic-power equation in detail
P_dynamic = ½ × C × V² × f
│ │ └─ frequency (Hz)
│ └─────── supply voltage (V)
└─────────────── switched capacitance (F)Voltage is squared — that's why voltage scaling historically gave the biggest power wins.
The power wall & dark silicon
| Era | Trend |
|---|---|
| 1978-1986 | Clock +15%/yr, performance +22%/yr |
| 1986-2003 (golden age) | Clock +40%/yr, performance +52%/yr |
| 2003+ (power wall) | Clock growth collapsed to < 2%/yr ⇒ industry shifted to multicore |
Why the wall?
A ~1.5 cm² die can only dissipate ≈ 100 W via air cooling. Dennard scaling broke around 2003 — transistors kept shrinking, but power density didn't fall to match. We hit a thermal ceiling.
Dark silicon
Modern chips have more transistors than we can safely power simultaneously. Large portions must stay dark (unpowered) at any moment to keep thermals in check. Power budgeting now limits architectural utility.
Memory hierarchy: where the energy goes
| Operation | Relative energy |
|---|---|
| 8-bit integer add | 1× |
| 32-bit float add | 30× |
| DRAM access | 2500× – 5000× |
Data movement, not compute, dominates modern energy budgets — which is why caches matter for green computing too.
Domain-Specific Architectures (TPU)
- 8-bit ints instead of fp32 → ~30× energy savings + ~60× area savings
- Scratchpad memory (software-managed) instead of inclusive caches → 2.5× less data-movement energy
- Result: TPU achieves 15-30× better perf/watt vs GPUs, up to 80× vs CPUs
Warehouse-scale: PUE
PUE
Power Utilization Effectiveness = Total Facility Power / IT Equipment Power
Lower is better. Ideal = 1.0. Industry average ~1.5. Google ~1.1.
Lower is better. Ideal = 1.0. Industry average ~1.5. Google ~1.1.
Modern data-centre tricks that drop PUE:
- Distributed UPS (99.99%) at the rack base, replacing central lead-acid (94%)
- 240 V AC → 48 V DC conversion at the rack, fewer conversion losses
- Higher ambient temperature (~80 °F) so evaporative cooling suffices, no chillers
Energy proportionality & the utilisation gap
Servers typically run at 10–50% utilisation, but consume ~50% of peak power even when idle. Goal of energy proportionality: 0 work → 0 power, scaling linearly. Dark silicon makes this harder.
Carbon intensity & Green AI
| Region | Grid mix | CO₂ per task |
|---|---|---|
| Pennsylvania | 25.5% coal | High |
| Wyoming | Coal-heavy | High |
| Iceland | Geothermal / hydro | Very low |
| Vermont | Hydro + nuclear | Very low |
Green AI
Accuracy plateaus while energy keeps climbing exponentially with model size. The new accountability frame: report carbon in human terms — e.g. "X kg CO₂ = N miles driven by a car" via CodeCarbon.
Green Computing — the iterated prisoner's dilemma
From the GreenComputing.png championship:
- 200-round N-player round-robin tournament
- Both cooperate = best collective outcome (lowest energy)
- Both defect = dominant individual strategy (everyone loses)
- Winning criterion: Efficiency Score = (W × 0.33) + (P × 0.33) + (C × 0.33)
Tracked with CodeCarbon for energy & emissions during the contest.
Source
Green Computing/GreenComputing.pdf §1-9 (power wall, dark silicon, DSAs, PUE, Green AI, carbon mix). Circuit_Cloud_Carbon.pdf for the deeper data-centre material.
Design Verification — the UVM picture
Q26 — must-know
Verilog is used to code microarchitecture (the actual datapath, control, gates). Not the ISA (architecture), not assembly, not high-level code.
UVM testbench anatomy
┌────────────────────────── TEST ───────────────────────────┐
│ ┌────────────────────── ENV ────────────────────────────┐ │
│ │ │ │
│ │ Coverage ◄──────────── analysis ports ──────────┐ │ │
│ │ ▲ │ │ │
│ │ ┌─ AGENT ──────────────────────┐ Predictor ──┤ │ │
│ │ │ Sequencer ─► Driver ─► DUT │ │ │ │ │
│ │ │ ▲ │ ▼ ▼ │ │
│ │ │ Monitor ◄─────┘ TLM FIFO ──► Scoreboard
│ │ └──────────────────────────────┘ (Expected vs Actual)
│ └──────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘Component cheatsheet
| Component | Role |
|---|---|
| Top module | Central integration; instantiates DUT, interface, calls run_test() |
| Test | Configures env, picks which sequences to run |
| Environment | Integrates Agent + Predictor + Scoreboard + TLM FIFO |
| Agent | Modular wrap of Driver + Sequencer + Monitor for one interface |
| Sequencer | Generates ordered sequence items (transactions) |
| Driver | Converts transactions → signal-level activity on DUT pins |
| Monitor | Passive: observes DUT signals → transactions, broadcasts via analysis port |
| Sequence Item | One transaction (built-in randomization/print/copy/compare) |
| Scoreboard | Checks DUT output against expected (predictor) output |
| Predictor | Reference model — produces expected output for a given stimulus |
| Coverage | Tracks which scenarios have been hit |
Data flow (memorise the arrows)
Two flows
Stimulus: Sequencer → Driver → DUT
Checking: DUT → Monitor → Analysis Port → { Scoreboard (actual) , Predictor → TLM FIFO → Scoreboard (expected) }
Checking: DUT → Monitor → Analysis Port → { Scoreboard (actual) , Predictor → TLM FIFO → Scoreboard (expected) }
Analogy
Sequencer = chef ordering dishes. Driver = waiter delivering them. Monitor = food critic at the table writing down what was actually served. Scoreboard = compares the critic's notes to the menu (predictor). Coverage = how many menu items have been ordered so far.
Counter DUT example (from demo session)
The lecture used an 8-bit counter as DUT with interface signals: reset, load, inc, data_in, q. Test sequences:
- Reset Sequence — initialize to 0
- Increment Sequence — repeated +1
- Load Sequence — load random values
- Random Sequence — random data + random op
Source
DesignVerification/Demo Session.pdf — full UVM block diagrams + counter example. Talk_On_Verification.pdf for the broader theory.
Up next: Worked Examples →