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
  • Part 7: Ordering13
    • Why Ordering Matters
    • Ordering Scopes
    • The Point of Serialisation
    • Early and Final Acknowledgement
    • Fences and Barriers
    • Ordering Tables
    • Relaxed and ID-Based Ordering
    • Same-Address Hazards
    • Interrupt and Data Ordering
    • Memory Consistency Models
    • Ordering Across Bridges
    • Protocols Compared: Ordering
    • Drills: Ordering
  • 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 7: Ordering
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 7: Ordering
  4. Drills: Ordering

Part 7 · Ordering · All levels

Drills: Ordering

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

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 can a consumer see the flag but old data?

    The two writes took paths that could reorder and nothing forced order; fix with one ordered path, a shared ID, a final acknowledgement, or a fence.

    Check yourself What ordering does AXI guarantee between different IDs?

    None; and none between the read and write channels.

    Check yourself Where is order decided in an interconnect?

    At the point of serialisation: where competing requests first pass through one in-order structure.

    Check yourself When the write response arrives, is the data in memory?

    Only if the response came from the destination; a bufferable write may be acknowledged early by a buffer.

    Check yourself How does a barrier work in hardware?

    It holds later accesses until earlier ones have completed to the promised point; every buffer on the path must drain or keep order.

    Check yourself Why may a read not pass a posted write in PCIe?

    Producer/consumer: a read-back must confirm earlier writes have landed.

    Check yourself Why are MSIs safer than wired interrupts?

    An MSI is a posted write that may not pass the device's earlier posted writes; a wire takes a separate path.

    Check yourself What reordering does x86 allow?

    Only a load passing an earlier store to a different address (store buffering).

    Whiteboard exercise

    Task. A NIC behind a PCIe-to-AXI bridge writes received packets into memory, then a completion entry, then an MSI. The bridge has four AXI write paths. Make the whole chain correct and fast.

    Check yourself Open a model answer

    On PCIe: the NIC marks packet-data writes Relaxed Ordering (if the platform enables it) and leaves the completion entry and the MSI strictly ordered. In the bridge: spread relaxed data writes across the four AXI IDs for throughput; keep strict writes ordered after every earlier write, either on one ID that the data writes also drain through, or by holding the completion entry until all earlier writes' responses have returned from the destination (non-bufferable, or an end-to-end acknowledgement). The MSI is held behind the completion entry the same way. In the driver: the handler reads the completion entry, checks its valid bit or sequence number, then reads the data. Verify with heavy inbound traffic and assert, in simulation, that no MSI or completion entry reaches its target before every earlier data write.

    Checkpoint: ten questions

    Check yourself 1. What is the data-then-flag pattern?

    A producer writes a payload, then a separate location announcing it; the consumer waits for the announcement, then reads the payload.

    Check yourself 2. Name four ordering scopes.

    Same ID, same address, same source to same destination, global.

    Check yourself 3. Why can two observers disagree on the order of writes to two targets?

    Each target serialises its own requests; nothing orders one target's against another's.

    Check yourself 4. What does an early acknowledgement still promise?

    That it will be performed, and that later writes in its ordering domain (as the specification defines it, not simply "the same path") will not overtake it.

    Check yourself 5. What is the cost of a fence?

    A stall until earlier accesses complete, and lost overlap across the fence.

    Check yourself 6. Give the two reasons behind every cell of a passing table.

    Producer/consumer correctness and deadlock avoidance.

    Check yourself 7. Which writes may be marked relaxed?

    Independent bulk data, never the flag that announces it.

    Check yourself 8. What prevents a read-after-write hazard through a write buffer?

    Forwarding or blocking on an address match, address-based routing, or waiting for the write's final acknowledgement.

    Check yourself 9. Which litmus outcome separates TSO from a weak model?

    Message passing seeing the flag but stale data: forbidden under TSO, allowed on weak models without barriers.

    Check yourself 10. What must a bridge never do with ordering?

    Add relaxation the source did not ask for (spread strict writes across IDs, mark traffic relaxed).

    Revisit

    • 7.1 Why Ordering Matters

    • 7.2 Ordering Scopes

    • 7.3 The Point of Serialisation

    • 7.4 Early and Final Acknowledgement

    • 7.5 Fences and Barriers

    • 7.6 Ordering Tables

    • 7.7 Relaxed and ID-Based Ordering

    • 7.8 Same-Address Hazards

    • 7.9 Interrupt and Data Ordering

    • 7.10 Memory Consistency Models

    • 7.11 Ordering Across Bridges

    Keep going

    Next: Part 8: Sharing and Arbitration. Who gets the wire when many want it?

    Previous

    116 / 234

    Next: Part 8: Sharing and Arbitration

    Up next

    Up nextPart 8: Sharing and Arbitration

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Ordering Matters
    • Ordering Scopes
    • The Point of Serialisation