An ESI service implementation which provides telemetry data through an MMIO
region. Each client request is assigned a register in the MMIO space. When a
read request is received for the assigned address, it gets routed to the
assigned client. When a write request is received, it is discarded. The
assignment table is stored in the manifest.
**REQUIREMENTS.** Both are needed to make the response merge safe:
1. The `MMIO` service implementation this connects to must not issue a read
command while a previous read's response is still outstanding.
2. Every telemetry client must assert its `data` channel's `valid` only in
response to a `get`. `Telemetry.report_signal` does this; a client which
holds `valid` high permanently -- legal ESI, and the natural way to
express an always-available counter -- does not.
Given both, each command is demuxed to exactly one client and at most one
client is offering a response at a time, so the responses can be merged with
`ChannelMergeOneValid` instead of arbitrated -- which keeps the response path
from building a combinational cone across every telemetry client.
Nothing here enforces either, and violating either loses responses. Note (2)
is not specific to this merge: `ChannelMux2` is fixed-priority, so under an
arbiter a permanently-valid client starves every client behind it.
Definition at line 776 of file common.py.