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

  • RTL Foundations57
  • Combinational Design58
  • Sequential Design61
    • Flip-Flops and Registers
    • Counters and Timers
      • Counting as Controlled State Evolution
      • Up/Down Counter with Reload
      • A Prescaler Feeding a Timer Tick
      • Watchdog Timer Example
      • A Gray-Code Counter
      • Key takeaways
      • Common pitfalls
      • Mini Project: a Programmable Timer
      • Worked Examples and Waveforms
      • Corner Cases and Stress Tests
      • Integration and Sign-off Notes
    • Shift Registers and LFSRs
    • Pipelining
    • Stalls, Bubbles and Hazards
    • Retiming
  • FSM & Control66
  • Timing & Clocking64
  • Reset & CDC58
  • Memory & Buses94
  • Advanced RTL60
  • Senior & Interview175
  • Glossary and Notation
Loading lesson

‹Counters and Timers
  1. Topics
  2. RTL Design
  3. Sequential Design
  4. Counters and Timers
  5. Key takeaways

Part 3 · Sequential · Senior Prep

Key takeaways

Counters and Timers: Key takeaways.

On this page

    Key takeaways

    Diagram
    KEY TAKEAWAYS
    
      ┌─────────┐     ┌──────────────┐     ┌─────────┐
      │ inputs  │ ──► │ sequential   │ ──► │ outputs │
      └─────────┘     │ mechanism    │     └─────────┘
                      └──────────────┘
                            │
                      pitfalls / when-to-use
                      (key-takeaways)
    • Use explicit reload and one-cycle terminal pulses for cleaner downstream logic.

    • Prescalers reduce power and simplify long timeouts.

    • Watchdog behavior should be deterministic at reset and kick boundaries.


    Deep dive

    This lesson deepens Key takeaways within sequential. Senior reviewers expect you to connect mechanism to register templates, pipelines, and flow control — not just define terms.

    Start from the spec invariant: what must always be true each cycle? Write it as a Boolean relation, timing budget, or protocol rule before coding. That invariant becomes your reference model, assertion, or waveform check.

    At tape-out quality, every block needs a sign-off story: reset complete, NBA in flops, pipeline latency documented. Treat this lesson as building one paragraph of that story for your project documentation.

    Architecture and signal flow

    Diagram
    KEY TAKEAWAYS
    
      inputs ──► [sequential] ──► mechanism ──► outputs
                    │                │
               counters-timers     verify in sim + lint

    Worked example (Verilog/SystemVerilog)

    Synthesizable pattern for this topic — simulate locally and compare against your reference.

    design.v
    1
    2
    3
    4
    always_ff @(posedge clk)
      if (!rst) cnt <= 0;
      else if (cnt==MAX) cnt <= 0;
      else cnt <= cnt + 1;

    Step-by-step design procedure

    1. Write the spec invariant (truth table, timing, or protocol rule).

    2. Sketch block diagram — inputs, outputs, clock/reset domains.

    3. Code the minimal correct version (no optimizations yet).

    4. Run self-checking TB with corners: min, max, reset, idle.

    5. Lint and review: width, latch, clock, CDC if applicable.

    6. Iterate for timing/area only after functionally proven.

    Timing and resource trade-offs

    Diagram
    METRIC          TYPICAL LEVER
    Logic levels      algebra / pipelining
    Register count    retiming / sharing
    Wire fanout       duplication / pipeline
    Power             clock gating / operand isolation
    Debug visibility  status flags / SVA / waveform probes

    Debug checklist

    • Compare DUT vs reference on every stimulus vector

    • Capture first cycle of mismatch — not last

    • Log seed and plusargs for random regressions

    • Check reset release and clock alignment in TB

    • If waveform is ambiguous, add temporary assertions

    Interview angle

    Pipeline stall vs bubble — when each?

    Diagram
    MODEL ANSWER SKELETON
    1. MECHANISM — one-sentence technical truth
    2. MOTIVATION — why this structure vs alternatives
    3. WHEN TO USE / SKIP — scope and assumptions
    4. PITFALL — common junior mistake
    5. EXAMPLE — Verilog or waveform scenario

    Practice exercise

    Extend the worked example for "Key takeaways": add one corner case, write a self-checking test, and document one intentional pitfall you avoided. Timebox: 30–45 minutes.

    Common pitfalls

    • Skipping reference model — passes wrong together with DUT.

    • Optimizing before correct — ECO cost goes up 10×.

    • Ignoring tool warnings — lint/CDC/STA warnings are technical debt.

    • Undocumented clock/reset domain — integration surprises.


    Extended design scenario

    Scenario for Key takeaways: Counter skips values after reset — verify sync release and enable gating.

    Scenario resolution outline

    1. Reproduce with minimal TB — one stimulus, one check.

    2. Isolate failing cone (logic, FSM state, or bus beat).

    3. Fix root cause — not symptom — in RTL or TB alignment.

    4. Add regression test that fails without the fix.

    5. Document invariant in comment or SVA for permanence.

    Additional simulation pattern

    design.v
    // Pipeline latency check
    repeat (PIPE_LAT) @(posedge clk);
    check_exp(dut_out);

    Synthesis and sign-off notes

    • Elaborate clean — no OOM from unconstrained generate

    • Constraints cover all clocks and I/O delays

    • Cross-check RTL parameters vs integration top

    • Attach sim log + seed to code review

    Lab exercise (45–60 min)

    Implement or extend the worked example for "Key takeaways". Add two new test vectors that target different branches. Write a one-paragraph sign-off note covering function, corners, and what you would still verify in SoC context.

    Further reading in this course

    Diagram
    Next topics in Part: follow nav_order in sidebar.
    Cross-part: timing ↔ sequential, CDC ↔ senior interview,
    combinational ↔ foundations number systems.

    Extended design scenario

    Scenario for Key takeaways: Counter skips values after reset — verify sync release and enable gating.

    Scenario resolution outline

    1. Reproduce with minimal TB — one stimulus, one check.

    2. Isolate failing cone (logic, FSM state, or bus beat).

    3. Fix root cause — not symptom — in RTL or TB alignment.

    4. Add regression test that fails without the fix.

    5. Document invariant in comment or SVA for permanence.

    Additional simulation pattern

    design.v
    // Pipeline latency check
    repeat (PIPE_LAT) @(posedge clk);
    check_exp(dut_out);

    Synthesis and sign-off notes

    • Elaborate clean — no OOM from unconstrained generate

    • Constraints cover all clocks and I/O delays

    • Cross-check RTL parameters vs integration top

    • Attach sim log + seed to code review

    Lab exercise (45–60 min)

    Implement or extend the worked example for "Key takeaways". Add two new test vectors that target different branches. Write a one-paragraph sign-off note covering function, corners, and what you would still verify in SoC context.

    Further reading in this course

    Diagram
    Next topics in Part: follow nav_order in sidebar.
    Cross-part: timing ↔ sequential, CDC ↔ senior interview,
    combinational ↔ foundations number systems.

    Extended theory

    Sequential logic is where protocols live: latency, handshake, reset sequencing, and pipeline bubbles are all register-scheduling problems—not RTL syntax problems.

    For "Key takeaways", the invariant you defend in review is: behavior matches spec under all legal input sequences, reset flows, and backpressure patterns—not just the happy path shown in introductory diagrams.

    Write the invariant as a comment above the module or as an SVA property when possible. Future you (and formal tools) will treat it as the contract.

    Waveform reading guide

    Diagram
    WAVEFORM NARRATIVE — Key takeaways
    
    cycle 0: reset asserted, outputs safe/idle
    cycle 1-2: reset held, clocks running
    cycle 3: reset released, first legal inputs
    cycle 4+: check output latency (N cycles)
    mark FIRST mismatch cycle — not last

    Second worked example

    Alternate pattern emphasizing debug, coverage, or integration:

    design.v
    1
    2
    3
    4
    // Clock-domain marker in TB
    always @(posedge clk) begin
      if (valid) $strobe("t=%0t data=%h", $time, data);
    end

    Comparison: naive vs production

    Diagram
    NAIVE APPROACH              PRODUCTION APPROACH
    quick hack, one sim vector    self-checking TB + corners
    ignore lint warnings          zero new waivers
    implicit widths               explicit casts/parameters
    undocumented latency          latency in module header comment

    Additional interview questions

    • Explain Key takeaways to a verification engineer — what would they assert?

    • What breaks first at high frequency or low voltage?

    • What is your rollback plan if synthesis QoR is unacceptable?

    • How would you debug this block with only a 32-bit GPIO trace?

    Follow-up interview model answer

    Diagram
    Q: What is the #1 mistake with Key takeaways?
    A:
      MECHANISM: [core rule in one line]
      MOTIVATION: why teams care in tape-out
      PITFALL: what juniors do wrong
      EXAMPLE: one Verilog line or one waveform event

    Hands-on lab part 2

    1. Fork the worked example; add one assertion or SVA cover.

    2. Inject a bug deliberately; confirm TB or assertion catches it.

    3. Write 5-bullet PR description for your change.

    4. Peer review: can a teammate enable the block without asking you?

    Sign-off evidence checklist

    • Directed sim log attached (PASS, seed noted)

    • Lint report clean for touched files

    • If sequential: reset + clocking section in README

    • If bus-facing: protocol cheat sheet in module doc

    • If timing-critical: note expected critical path endpoint

    Previous

    131 / 694

    Next: Common pitfalls

    Up next

    Up nextCommon pitfalls

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Counting as Controlled State Evolution
    • Up/Down Counter with Reload
    • A Prescaler Feeding a Timer Tick