The course has about 280 lessons in fourteen sections, which is more than anyone needs for one goal. This page gives three routes. Each is an ordered table of real lessons with the reason to read it and an approximate time, so you can plan a week instead of guessing. Every route starts from the chip described in The NanoSoC Tour and assumes you have read How to Use This Course.
A lesson read once takes about 10 minutes. Lessons with a longer worked example or a program to run are listed at 12 or 15. Working every example, changing numbers and answering every check-yourself roughly doubles it: about 18 minutes a lesson. Multiplying by the lesson counts below gives the course totals quoted on the hub: about 45 hours to read, about 80 with the exercises. These are planning estimates for a reader who already knows RTL and timing basics, not measurements of learners. Treat them as the size of the job, and expect the first few lessons to run slower while the NanoSoC names settle.
Section | Lessons (approx.) | Read once (hours, approx.) |
|---|---|---|
12 | 2.0 | |
21 | 3.5 | |
26 | 4.5 | |
26 | 4.3 | |
24 | 4.0 | |
21 | 3.5 | |
15 | 2.5 | |
21 | 3.5 | |
21 | 3.5 | |
21 | 3.5 | |
18 | 3.0 | |
18 | 3.0 | |
16 | 2.5 | |
19 | 3.2 |
Read these essential lessons in section order. All other lessons are optional depth or reference, except the capstone: its five entries are milestones, and each stage needs all three of its challenge lessons before proceeding. Plan roughly 7 to 9 hours for a first read of the 44 listed milestones; this is an editorial estimate, with additional time for the capstone investigation and runnable examples. Open Solutions only after writing your diagnoses and readiness statement.
You own one block today. This route takes the ideas a block owner is missing: that the map, the clocks, the resets and the wiring tables are your deliverables. It follows the chip in order and picks the one or two lessons per section that change how you think; read the rest of a section when a lesson leaves a question. About 4.1 hours as listed.
Lesson | Why you read it | Minutes |
|---|---|---|
The one chip every later lesson uses: blocks, clocks, map, boot. Keep it open. | 30 | |
Names the things you now answer for that a block owner never did. | 10 | |
What arrives with a block and what you must ask for before you wire it. | 10 | |
The first budget a block owner never builds: peak against sustained rate per link. | 12 | |
The map is the contract between hardware, firmware and every test. | 10 | |
Where the NanoSoC DMA alias comes from and why a hole is not a bug. | 10 | |
How a window becomes a comparison on address bits. | 10 | |
Three error answers, three different places in the chip that give them. | 10 | |
The bridge every slow register block sits behind. | 10 | |
The protocol rules that integration mistakes break first. | 10 | |
Why clocks from one PLL are still signed off as asynchronous. | 10 | |
The crossing inventory: nothing multi-bit crosses without a handshake or FIFO. | 12 | |
Slaves and fabric first, CPU last, with the numbers. | 12 | |
Isolation before reset before power off. | 12 | |
Level, polarity and the two flops on every controller input. | 10 | |
The two LEN registers that must agree, and what happens when they do not. | 12 | |
Boot as a timeline: where 12.581 ms goes. | 12 | |
Wiring written as a table you can check by machine. | 10 | |
Turn the map and the interrupt table into tests. | 10 | |
Which violations may be excused, and who decides. | 10 | |
Start the capstone: it spends everything above. | 15 |
You already assemble subsystems. This route concentrates on contracts, governance, handoff gates, the evidence behind a signoff and the decisions around the readiness review. It assumes the block-owner route, or equivalent experience, for maps, fabric, clocks, resets and power. About 4.0 hours as listed.
Lesson | Why you read it | Minutes |
|---|---|---|
The shared reference chip. Skim if you know it. | 20 | |
An interface is only as good as the written contract behind it. | 10 | |
Who decides, who is consulted, and how a change travels. | 10 | |
A budget with no owner is a wish. | 10 | |
How margin is spent over the schedule and when to stop it. | 10 | |
What you still review when the top is generated. | 10 | |
Which layer enforces which access rule. | 10 | |
The cyclic-wait patterns you must rule out. | 12 | |
The review you will run on every crossing. | 10 | |
The gate a delivery passes before it enters the top. | 10 | |
Every exception is a claim about the design: review it as one. | 10 | |
What block-level verification cannot see. | 10 | |
Evidence that survives a baseline change. | 10 | |
The review that locks the package interface. | 10 | |
The list of evidence the chip is judged on. | 10 | |
What a frozen baseline contains and what it forbids. | 10 | |
Every excuse carries a clock. | 10 | |
What each owner must bring to the review. | 10 | |
How the decision is taken and recorded. | 10 | |
What tends to appear when the baseline is already frozen. | 10 | |
What happens to a bug that escapes. | 10 | |
Close the loop: check a manifest and call readiness. | 15 |
Fourteen days, about 6.8 hours in total, so a little under an hour a day. Each day pairs the lessons that teach a subject with the interview-prep page that tests it. Say the answers aloud: an answer you only read is not yet an answer. If you have less time, keep days 1, 5, 6, 11 and 13.
Day | Lesson | Why you read it | Minutes |
|---|---|---|---|
Day 1 | Learn the chip you will draw from memory. | 30 | |
Day 1 | The answer shape the later days reuse. | 10 | |
Day 1 | What an interviewer probes and the drawings that answer it. | 10 | |
Day 2 | Maps are the most common opening question. | 10 | |
Day 2 | Be exact about which layer answers with which code. | 10 | |
Day 3 | The protocol facts interviewers use to separate levels. | 10 | |
Day 3 | A classic integration question with a clean answer. | 10 | |
Day 4 | Peak against sustained, per link. | 12 | |
Day 4 | Practise the arithmetic aloud. | 25 | |
Day 5 | Name each crossing and its mechanism. | 12 | |
Day 5 | Release order with the NanoSoC numbers. | 12 | |
Day 5 | Reset, clock, interrupt and pad arithmetic. | 25 | |
Day 6 | The three states and what each keeps. | 10 | |
Day 6 | The sequence answer: isolate, reset, power off. | 12 | |
Day 6 | Power, queue and synchroniser arithmetic. | 25 | |
Day 7 | Trace one interrupt end to end. | 12 | |
Day 7 | A favourite whiteboard bug. | 12 | |
Day 7 | Boot as a timeline with shares. | 12 | |
Day 8 | The security partition and where it is enforced. | 10 | |
Day 9 | What you demand from a block owner. | 10 | |
Day 9 | Connectivity as data. | 10 | |
Day 10 | Pad counts as arithmetic. | 10 | |
Day 10 | Estimate switching noise and size the supply pads. | 12 | |
Day 10 | Waivers: what, who, how long. | 10 | |
Day 11 | Time-box the open design question. | 12 | |
Day 11 | Compare your drawing with a model. | 15 | |
Day 12 | Handle the three usual follow-ups. | 12 | |
Day 13 | Debug several failures that arrive together. | 15 | |
Day 13 | Defend a number under pressure. | 15 | |
Day 14 | Review all ten planted bugs and what catches each. | 15 |
Keep the whiteboard framework and the numeric drills, since they train the method, plus one subject day each on maps, clocks and resets, and power. Give up the section rapid-fire pages and the scenario days, which reward breadth you cannot build in three days.