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
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
    • Latency, Throughput and Bandwidth
    • Little's Law
    • Outstanding Transactions
    • Tags and IDs
    • In-Order or Out-of-Order
    • Reorder Buffers
    • Interleaving
    • Split Completions
    • Protocol Efficiency
    • Peak and Sustained Bandwidth
    • Queueing Intuition
    • Tail Latency
    • Buffers That Hide Latency
    • Virtual Output Queues
    • Performance Modelling
    • Protocols Compared: Concurrency and Performance
    • Drills: Concurrency and Performance
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 6: Concurrency and Performance
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 6: Concurrency and Performance
  4. Drills: Concurrency and Performance

Part 6 · Concurrency and Performance · All levels

Drills: Concurrency and Performance

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

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 Can you lower latency and lose bandwidth?

    Yes: fewer pipeline stages (lower clock), smaller packets (more header overhead), or no batching all cut latency and cost bandwidth.

    Check yourself 100 ns latency, 64-byte lines, 25.6 GB/s: how many outstanding reads?

    400 million lines/s × 100 ns = 40.

    Check yourself How many tag bits do you need?

    Enough tags for rate × worst round trip: one request per cycle and 300 cycles needs 300 tags, so 9 bits.

    Check yourself Where would you put a reorder buffer?

    At the requester that needs order, sized by Little's law in whole responses, with slots reserved at request time.

    Check yourself Why does AXI4 forbid write data interleaving?

    Every target would need per-ID reassembly state; read interleaving costs only requesters, which already track IDs.

    Check yourself A x4 Gen3 link: what payload bandwidth?

    4 GB/s line, 3.94 after 128b/130b, about 3.6 with 256-byte payloads after 24 bytes per packet, a little less after link-management packets.

    Check yourself Why does latency explode near full load?

    Random arrivals queue; for a simple queue latency is 1/(1 − load): 10× at 90%.

    Check yourself Your average is fine but p99 fails. Where do you look?

    Bursts near the knee, rare long events, head-of-line blocking, unfair arbitration and fan-out; get a histogram under load.

    Whiteboard exercise

    Task. An accelerator streams reads from memory at 32 GB/s in 64-byte lines. Round trip: 150 ns typical, 400 ns worst case under load. Size its tag pool and reorder buffer, and say what the memory must sustain.

    Check yourself Open a model answer

    Rate: 32 GB/s ÷ 64 B = 500 million lines per second. Tags: 500e6 × 400 ns = 200 outstanding at the worst-case round trip (the typical 150 ns round trip would need only 75), so 256 tags, 8 bits. Reorder buffer, if the accelerator needs order: 200 slots × 64 B = 12.8 KB, slots reserved when each request is issued so every response can be accepted. Memory: 32 GB/s sustained, not peak; with 64-byte random-ish accesses a memory may sustain only 60–75% of peak, so the memory system should be specified at roughly 45–55 GB/s peak, and checked with a model at the real access pattern. Latency at that load should be read off the queueing curve, which is why the worst case is 400 ns rather than 150.

    Checkpoint: ten questions

    Check yourself 1. State Little's law.

    Items in flight = throughput × latency (averages, any stable system).

    Check yourself 2. A requester allows 8 outstanding with a 40-cycle round trip. Its maximum throughput?

    8/40 = 0.2 per cycle.

    Check yourself 3. When may a tag be reused?

    Only after the last response for it has arrived.

    Check yourself 4. In AXI, which transactions keep their order?

    Those with the same ID.

    Check yourself 5. Why must a ROB reserve slots at request time?

    So every requested response can be accepted; otherwise the fabric can deadlock.

    Check yourself 6. What may a PCIe completer split a large read on?

    Naturally aligned Read Completion Boundaries, with each piece within the maximum payload size.

    Check yourself 7. Efficiency for payload P and per-packet overhead O?

    P / (P + O).

    Check yourself 8. Name three per-access overheads that keep DRAM below peak.

    Bus turnaround, row misses, refresh (and command gaps).

    Check yourself 9. Why does fan-out make the tail matter?

    An operation waiting for many requests is as slow as the slowest; a 1% tail per request becomes common for the whole.

    Check yourself 10. What limits a FIFO-input switch under random traffic?

    Head-of-line blocking: about 60% (58.6% for large switches).

    Revisit

    • 6.1 Latency, Throughput and Bandwidth

    • 6.2 Little's Law

    • 6.3 Outstanding Transactions

    • 6.4 Tags and IDs

    • 6.5 In-Order or Out-of-Order

    • 6.6 Reorder Buffers

    • 6.7 Interleaving

    • 6.8 Split Completions

    • 6.9 Protocol Efficiency

    • 6.10 Peak and Sustained Bandwidth

    • 6.11 Queueing Intuition

    • 6.12 Tail Latency

    • 6.13 Buffers That Hide Latency

    • 6.14 Virtual Output Queues

    • 6.15 Performance Modelling

    Keep going

    Next: Part 7: Ordering. In what order do results become visible, and who decides?

    Previous

    103 / 234

    Next: Part 7: Ordering

    Up next

    Up nextPart 7: Ordering

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Latency, Throughput and Bandwidth
    • Little's Law
    • Outstanding Transactions