Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • Meet DCRouter
  • Glossary
  • Part 0: What Verification Is8
  • Part 1: What Can Go Wrong11
  • Part 2: Specifications as Checkable Rules8
  • Part 3: Observability and Controllability7
  • Part 4: Stimulus11
  • Part 5: Checking11
  • Part 6: Coverage10
  • Part 7: Formal and Simulation10
  • Part 8: Verification Levels and Reuse8
  • Part 9: Planning and Risk9
  • Part 10: Emulation and Prototyping8
    • Why Cycles Matter
    • Simulation Speed and Its Limits
    • Emulation
    • FPGA Prototyping
    • Virtual Platforms and Hybrids
    • Debug at Scale
    • Choosing the Platform
    • Drills: Emulation and Prototyping
  • Part 11: Post-Silicon Validation8
  • Part 12: Bug Economics8
  • Part 13: Debug7
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 10: Emulation and Prototyping
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 10: Emulation and Prototyping
  4. Drills: Emulation and Prototyping

Part 10 · Emulation and Prototyping · All levels

Drills: Emulation and Prototyping

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 10.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself Why emulation?

    Some questions need billions of cycles (OS boot, driver workloads, long random runs); whole-chip simulation is far too slow.

    Check yourself How would you speed up a slow regression?

    Profile, then simulate less design, do less work per cycle, run fewer cycles per question, and parallelise.

    Check yourself Emulation or FPGA prototype?

    Emulation for boot, bring-up and debug with visibility; prototypes for long, fast software runs and real peripherals on stable RTL.

    Check yourself What does an FPGA prototype miss?

    Real timing, memories, analogue and power behaviour, and it adds artefacts of its own; it also shows little of the inside.

    Check yourself How does software start before RTL?

    On a virtual platform of register- and function-accurate models, then hybrids with real RTL for new blocks.

    Check yourself How do you debug on an emulator?

    Detect early with synthesised assertions, capture trace windows around triggers, log transactions, checkpoint, and replay in simulation.

    Check yourself Which platform for which goal?

    The cheapest that answers the question in time, by cycles, accuracy, visibility, turnaround and availability.

    Whiteboard exercise

    Task. A camera SoC has an image pipeline, a DDR controller, a USB device port and an ARM-class processor running Linux. Tape-out is in nine months. Assign platforms to these goals and say when each becomes possible: verify the pipeline's filters; bring up the USB driver; boot Linux; measure frame rate at 4K; check behaviour at low voltage.

    Check yourself Open a model answer

    Pipeline filters: block simulation against a bit-accurate C model, with formal on the control logic; from RTL availability. USB driver: virtual platform with a USB device model from the specification stage, then a hybrid with the USB RTL in simulation or emulation once it exists, then the FPGA prototype with a real host cable. Linux boot: virtual platform early for software, emulation once the full RTL compiles (around RTL freeze minus three months), FPGA prototype for software teams afterwards. 4K frame rate: an architecture performance model early for expectations, emulation with real frames for measurement, prototype for long runs; confirm on silicon. Low voltage: only silicon (characterisation, Part 11), prepared by running the same test programs earlier on emulation so they are ready on day one.

    Checkpoint: ten questions

    Check yourself 1. How long does a 5-billion-cycle OS boot take at 1 kHz and at 1 MHz?

    About 58 days and about 83 minutes.

    Check yourself 2. Why don't more simulation machines speed up one long test?

    Each test runs on one machine; parallelism raises throughput only.

    Check yourself 3. What cut the constraints demo from 26 to 6 seconds?

    Fewer randomize() calls (about 4,500 instead of 21,000).

    Check yourself 4. Why can a signal-level testbench slow an emulator down?

    The emulator waits for the host on every cycle the testbench exchanges signals.

    Check yourself 5. What is a transactor?

    A synthesisable driver or monitor that converts transactions from the host into cycles on the emulator.

    Check yourself 6. Name an artefact an FPGA prototype can add.

    A crossing or delay between FPGAs that the real chip does not have.

    Check yourself 7. Why did the driver developed on a virtual platform fail on the emulator?

    The virtual DMA completed instantly; the real one took time and the driver assumed instant completion.

    Check yourself 8. What turns a software timeout into a precise hardware event on an emulator?

    A synthesised assertion, such as DCRouter's R13 wake check, firing at the cycle the rule breaks.

    Check yourself 9. What do checkpoints save during debug of a late failure?

    Re-running the billions of cycles before the failure for each attempt.

    Check yourself 10. Which platform answers "does it work at low voltage"?

    Silicon.

    Revisit

    • 10.1 Why Cycles Matter

    • 10.2 Simulation Speed and Its Limits

    • 10.3 Emulation

    • 10.4 FPGA Prototyping

    • 10.5 Virtual Platforms and Hybrids

    • 10.6 Debug at Scale

    • 10.7 Choosing the Platform

    Keep going

    Next: Part 11: Post-Silicon Validation. What do we do when the chip comes back?

    Previous

    106 / 160

    Next: Part 11: Post-Silicon Validation

    Up next

    Up nextPart 11: Post-Silicon Validation

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Cycles Matter
    • Simulation Speed and Its Limits
    • Emulation