These three sections own the decisions everything else implements: what the chip is, what each block may spend, and where everything lives. Interviewers probe them first because a weak map or an unowned budget poisons every later answer. Expect open questions here, not definitions: the interviewer wants to hear you own the contracts.
Q1: What does the SoC integrator own that block owners do not. Model: the integrator owns everything between blocks, the map, the fabric configuration, the clock and reset plans, the power sequence, the interrupt table, the boot flow and the top-level checks. Block owners own their RTL meeting its contract; the integrator owns the contracts agreeing with each other. Follow-up: who signs when two contracts conflict. Answer: the integrator proposes, the architect or the budget owner from the RACI disposes, and the decision log records it.
Q2: Name the integration gates from specification to tapeout. Model: map freeze, fabric freeze with arbitration and outstanding limits, clock and reset plan review, power intent review, connectivity clean, boot in simulation, performance against budget, signoff matrix complete with waivers classified. Each gate has an owner and entry criteria; a gate without criteria is a meeting. Follow-up: which gate catches the alias bug. Answer: the map-versus-RTL consistency check at connectivity clean, backed by the elaboration-time overlap assertion.
Q3: Why front-load integration checks. Model: the cost of a bug rises by roughly an order of magnitude per stage escaped, so a map overlap caught by a script costs minutes and caught in silicon costs a respin. Front-loading means generation from one source, lint and formal connectivity before simulation. Follow-up: name one check that only exists at top level. Answer: the master-to-slave reachability matrix, because no block test bench sees two masters and one secure region at once.
Q4: Hardware-software contract in one minute. Model: the contract is the map, the register definitions with access types, reset values, interrupt numbers and polarity, plus the errata list with workarounds. It is generated from the same source as the RTL so headers cannot drift. Follow-up: what breaks first when it drifts. Answer: the header, because software changes fastest, so the register-model-versus-RTL check runs in the build.
Q5: How do block budgets become contracts. Model: the architect's ledger assigns each block area, power, timing and bandwidth with margin, and each assignment becomes a signed contract with a burn-down the integrator tracks. Missing a budget triggers rebalancing, descope or a margin draw with an owner and a date. Follow-up: who owns the margin. Answer: the integrator holds it centrally and lends it against the log; owners never spend each other's margin directly.
Q6: Size a bandwidth budget for one initiator. Model: demand equals bytes per transfer times rate, sustained supply equals width times clock times burst efficiency, and usable DRAM is peak times an efficiency that depends on the workload (a general guideline is 60 to 85 percent). Sum all masters against usable, not peak. Follow-up: where does NanoSoC's 361.4 come from. Answer: 4 bytes times 96 MHz times 16 over 17 for one idle cycle per 16-beat burst.
Q7: Shared bus, crossbar or NoC for eight masters and twelve slaves. Model: a shared bus fails on concurrency, a crossbar works to about this size with round-robin arbitration, and a NoC wins when masters exceed a dozen or clocks and power split the die into regions. NanoSoC's two-by-four fabric is a crossbar because two masters cannot justify a NoC. Follow-up: what breaks first as masters grow. Answer: the hotspot slave port and the arbitration fairness, so separate request and response paths before adding routers.
Q8: Utilisation 69.7 percent: headroom or waste. Model: the core is 0.655 mm² against a 0.940 budget, leaving 0.285 for engineering change orders, routing growth and late features. As a general guideline, a die far below 60 percent utilisation wastes silicon and one above about 80 percent leaves no room to fix anything. Follow-up: what consumes the headroom first. Answer: usually the power grid and late pipeline stages, so track them in the burn-down.
Q9: Draw the rules for sizing a region. Model: round the need up to a power of two, align the base to the size, waste is size minus need, and select bits are the address width minus the log of the size. A 40 KB need takes 64 KB aligned to 64 KB. Follow-up: who pays the waste. Answer: the map pays in holes, which must answer DECERR loudly rather than aliasing silently.
Q10: DECERR versus SLVERR versus PSLVERR. Model: DECERR means no slave exists at the address and comes from the default slave; SLVERR means a slave refused, for example a secure-only region hit non-secure; PSLVERR is the APB form, converted to SLVERR by the bridge. Software treats DECERR as a linker-script bug and SLVERR as a permission or state bug. Follow-up: which one does NanoSoC's APB hole return. Answer: PSLVERR from the slot decoder, seen by software as SLVERR.
Q11: What is the DMA alias and why is it legal. Model: the DMA decodes only 8 address bits behind a 12-bit slot, so its 256-byte window repeats 16 times across the 4 KB slot. It is legal because offsets 0x14 to 0xFF still fault and software uses only the first image. Follow-up: what lint rule keeps it legal. Answer: the connectivity check that the upper slot bits reach no slave, plus the rule that software touches only 0x4000_0000 to 0x4000_00FF.
Q12: Secure region design in three sentences. Model: mark SRAM1 secure-only, enforce AxPROT at the interconnect and per slot at the APB decoder, and return SLVERR to non-secure accesses. Filters sit at the slave so no master bypasses them. Follow-up: how do you test it. Answer: a per-master reachability matrix plus directed non-secure accesses expecting SLVERR on every secure register.
The NanoSoC-specific one: the APB hole answers PSLVERR from the slot decoder and software sees SLVERR, while the fabric holes answer DECERR from the default slave. Knowing which block generates which code, and what software should conclude from each, is the specific and mostly correct answer; naming the code alone is generic.