# Week 12 — Quiz
Ten questions — a capstone-readiness check. Each answer is folded under its question.
**1. The most common capstone failure in hardware is:**
- A. too much documentation
- B. too small a design
- C. scoping too big to finish verifying or close timing
- D. using open-source tools
Answer
**C. scoping too big to finish verifying or close timing** — An unverified or un-closed design does not run — scope for done and signed off.
**2. A capstone design's correctness must rest on:**
- A. verification against an independent golden model
- B. the fact it synthesizes
- C. a fast clock
- D. it looking right in the waveform
Answer
**A. verification against an independent golden model** — Unverified means untrusted; check bit-exact against a reference.
**3. Getting the whole RTL-to-bitstream flow working early, on a stub, is:**
- A. unnecessary with open tools
- B. a waste of time
- C. the way to de-risk the project before deepening it
- D. only for CPUs
Answer
**C. the way to de-risk the project before deepening it** — A finished B+ that closed beats an unfinished A+ that never did.
**4. For a capstone you must report:**
- A. the target frequency you hoped for
- B. no timing number
- C. only the LUT count
- D. the Fmax static timing analysis actually achieved, with committed constraints
Answer
**D. the Fmax static timing analysis actually achieved, with committed constraints** — Report the achieved frequency, reproducibly — the course's central ethic.
**5. If you use an open-source UART core in your capstone you must:**
- A. claim you wrote it
- B. cite it and honor its license
- C. hide that you used it
- D. remove all comments
Answer
**B. cite it and honor its license** — Passing off or mis-licensing others' RTL is misconduct regardless of the technical work.
**6. A reproducible capstone repo needs:**
- A. a screenshot
- B. nothing extra
- C. only the bitstream
- D. a scripted flow, committed constraints, the testbench, and pinned tool versions
Answer
**D. a scripted flow, committed constraints, the testbench, and pinned tool versions** — Others must reproduce both your verification and your timing number.
**7. When a design works in simulation but misbehaves on the board, the first ethic to recall is:**
- A. simulation is not silicon — debug the real signals (clock, reset, pins, synchronizers)
- B. the tool is broken
- C. give up
- D. report it as working anyway
Answer
**A. simulation is not silicon — debug the real signals (clock, reset, pins, synchronizers)** — Bring-up starts from the simplest signal; check timing margin and async inputs.
**8. A good capstone README leads with:**
- A. what the system does, a block diagram, and honest verification/timing results
- B. the raw source with no explanation
- C. the tool install log
- D. only the limitations
Answer
**A. what the system does, a block diagram, and honest verification/timing results** — Lead with what it does and proves; show a result early; state limitations.
**9. If you cannot close timing at your target, the professional response is:**
- A. report the best honest Fmax, the limiting path, and what better would take
- B. delete the timing report
- C. claim the target anyway
- D. fake the report to say 'met'
Answer
**A. report the best honest Fmax, the limiting path, and what better would take** — A well-analyzed honest ceiling is a result; a faked number is misconduct.
**10. The best capstones handle their weaknesses by:**
- A. skipping verification
- B. hiding them
- C. explaining them honestly — what works, the real Fmax, what's verified, and next steps
- D. overclaiming
Answer
**C. explaining them honestly — what works, the real Fmax, what's verified, and next steps** — Honest limitations read as competence; in hardware, overclaiming is quickly audited.
---