Implement a single-entry elastic buffer (a pipeline register) using the standard valid/ready handshake convention found in AXI-Stream and most modern streaming hardware interfaces. This is one of the most commonly asked "real-world" RTL interview questions, because getting backpressure exactly right — never dropping data, never violating the protocol, and achieving full throughput when possible — is harder than it first looks. Ports: - `clk` — input, 1 bit, clock - `rst` — input, 1 bit, synchronous active-high reset - `in_valid` — input, 1 bit, upstream asserts this when `in_data` holds valid data - `in_data` — input, 8 bits (`in_data[7:0]`), data presented by upstream - `in_ready` — output, 1 bit, this module asserts this when it can accept data from upstream this cycle - `out_valid` — output, 1 bit, this module asserts this when `out_data` holds valid data for downstream - `out_data` — output, 8 bits (`out_data[7:0]`), registered data presented to downstream - `out_ready` — input, 1 bit, downstream asserts this when it can accept data this cycle Handshake convention: a transfer occurs on the upstream interface on any cycle where `in_valid` and `in_ready` are **both** high; likewise, a transfer occurs on the downstream interface on any cycle where `out_valid` and `out_ready` are **both** high. Upstream must never change `in_data` or deassert `in_valid` while `in_valid` is high and `in_ready` is low (i.e., once data is offered, it stays offered until accepted) — the testbench will respect this rule, and your design does not need to handle a violation of it. Required behavior, synchronous to `clk`: 1. The buffer holds at most one item internally. If `rst` is high, the buffer synchronously clears to empty (`out_valid` becomes 0), overriding everything else. 2. `in_ready` must be 1 whenever the buffer is empty (always able to accept), and must **also** be 1 even when the buffer is full, as long as `out_ready` is high that same cycle (because the item occupying the buffer is being drained out this very cycle, freeing space for the incoming item in the same cycle — this is what allows full one-item-per-cycle throughput with zero bubble cycles when both sides are continuously active). In every other case (buffer full and `out_ready` low), `in_ready` must be 0 — upstream's data must never be silently dropped or overwritten while the buffer has nowhere to put it. 3. `out_valid` reflects whether the buffer currently holds an item; `out_data` is the item itself. 4. On a cycle where an upstream transfer occurs (`in_valid && in_ready`), the buffer's contents become `in_data` (replacing whatever was there, including the item being drained out that same cycle, if any) and `out_valid` becomes/stays 1. 5. On a cycle where **no** upstream transfer occurs but a downstream transfer does (`out_valid && out_ready`, with no simultaneous accepted input), the buffer becomes empty (`out_valid` becomes 0) on the next cycle. 6. If neither condition applies, the buffer's contents and `out_valid` are unchanged. The key correctness property graded here: across any sequence of `in_valid`/`out_ready` toggling, including upstream repeatedly offering data while downstream stalls, no item is ever lost or duplicated, `in_ready` never lies about available space, and back-to-back transfers achieve full throughput (no unnecessary bubble cycles) whenever both sides are continuously active.