The course is organised as fourteen sections. Most sections have five to seven topics, and each topic has a short hub page plus about three lessons. A lesson is short enough to read in one sitting and is built to one pattern, so you always know where to look for the idea, the numbers and the pitfall.
Three companions carry the mechanism this course spends. Read them before the sections that lean on them, not necessarily before the course.
If this is new | Read this first | Before sections |
|---|---|---|
RTL hierarchy and bus structure | Architecture, memory maps, interconnect | |
Reset strategies in RTL | Clock and reset architecture | |
Clock architecture and gating | Clock and reset architecture, power | |
Crossings and synchronisers | Clock and reset architecture, interrupts | |
AXI, AHB, APB and streams | AXI4, AHB, APB and AXI-Stream | Memory maps, interconnect, DMA |
Timing constraints and signoff | IP integration, chip signoff | |
Verification levels | Top-level verification and bring-up |
Part | What it gives you |
|---|---|
Why it matters | The problem the idea solves on NanoSoC, in a few sentences, usually a symptom. |
Core idea | How it works at the top level, with a table or a formula. |
Worked example | Numbers, as a table, a short calculation or a runnable Python block that asserts them. |
What the review looks for | The checks an integration reviewer would apply to this step. |
How to verify or debug it | What to measure and where to look when the result is wrong. |
Pitfall callout | The common mistake, ideally a real NanoSoC failure mode, and why it looks reasonable until it fails. |
Interview callout | How the idea is asked in interviews and what a strong answer contains. |
Check yourself | A question with a hidden answer: answer it first. |
Related lessons | Links backwards and forwards, and to the owner course where the mechanics live. |
The capstone uses a challenge pattern instead. The brief and the stage lessons give the observation to investigate, the required behaviour, the inputs to start from, a deliverable with its pass criterion, and the evidence to hand in; the answers and the runnable worked checks sit in a separate Solutions topic that you open after your own investigation. Section and topic hubs are shorter: a purpose paragraph, a table of what you can do after each page and a suggested order.
Python 3.8 or newer works. The blocks use only the standard library: no packages, no files, no network and no randomness without a fixed seed.
Copy a block into a file or paste it into an interpreter. Each one finishes in well under a few seconds and prints exactly one line starting with PASS if its assertions hold.
If an assertion fails you will see which one. Change a number and see which assertion breaks: that is the quickest way to learn which relationship the lesson is about.
A block that cannot run here starts with a comment of the form not-run and a reason. Format fragments, such as a few lines of IP-XACT or UPF, are marked the same way: they are explained, not executed.
Every invented number is labelled illustrative. It is consistent inside its lesson, so the arithmetic can be checked, but it is not a target and not typical of any named process, library or product.
Numbers quoted from the running chip are labelled NanoSoC teaching values. They are exact inside the course: every lesson quotes the same address, the same frequency, the same latency.
Area and power figures are NanoSoC teaching values built on stated assumptions, a generic planar process at 0.9 V with fixed leakage densities, and are not measurements of any real chip.
Exchange formats are real and standard: AMBA AXI, AHB and APB, IP-XACT, UPF, SDC, Liberty, LEF and DEF, GDSII and OASIS, and JTAG. Fragments of them are shown as text blocks and explained.
Reports are shown in an illustrative generic format with a few columns. They are not output from any commercial or open-source tool; the text says the interconnect generator, the lint tool or the signoff checker rather than naming a product.
NanoSoC is one chip, and the course builds it together. The address map decoded in the memory-map section is the map the DMA streams through in the interconnect section, the fabric the power controller isolates in the power section, and the memory the boot code loads in the boot section. When a lesson says the SBR reads SRAM0 while writing SRAM1, those are the same two 64 KB memories from The NanoSoC Tour, at 0x2000_0000 and 0x2001_0000, on the same 96 MHz fabric. Learn the tour first and every later number lands on ground you have walked.
Aim | How to read |
|---|---|
A project in six months | Follow your role path end to end. Run every Python block, change its inputs, and do the capstone with the checker, because the capstone is the closest thing to the job. |
A project starting now | Read the tour, then only the sections your task touches, top to bottom. Skim the worked tables even if you skip the scripts; the numbers carry the teaching. |
An interview in two weeks | Read the tour, then Interview Prep: the framework, the scenarios, the rapid-fire rounds. Say every answer aloud in the order Assumption, Mechanism, Trade-off, Evidence, and draw the diagram before you speak. |
Never skip the check-yourself questions or the interview callouts: they are the shortest way to find a gap. Cut breadth before depth: skip whole topics you will not use before skimming every topic.
If a number disagrees with The NanoSoC Tour, the tour wins and the lesson is wrong: quote both pages, the two values, and which assertion fails. If a Python block fails on a fresh copy, quote the block, your interpreter version, and the first failing assertion. If a link points nowhere, quote the lesson and the link text. One report per message keeps each fix checkable.
So that no value is mistaken for a target or a fact about a real process: the arithmetic is the lesson, and limits come from the project's own policy and the foundry's rules.