@nprofile1q... if you'd like to generate HAL/C headers with register defs, yes. The non-arm standard description would be SystemRDL from the same consortium that brought you IP-XACT (you decide whether that's a good thing).
PeakRDL to translate between description and C headers/rust crates/python modules/chisel design/SystemVerliog/VHDL…

@nprofile1q... is this half- or full-duplex?

@nprofile1q... yep, need to shift the time values to a "local environment" if you will (extreme example: the interpolator doesn't care about absolute time, you can always shift all times by an integer value so they're zero-centered, locally)

@nprofile1q... yeah, never keep time in floating point; it's typically not a thing where that makes a lot of sense (this was learned by SDR software *several* times). Your timestamps should just be int64 multiples of some pre-defined time quantum, and you'll be fine. You don't need sub-attosecond accuracy, and neither do you need to be able to measure in millions of years; the fixed 64 bit range suffices.

@nprofile1q... or you might be someone with enough statistics to say which parameters correlate with trouble, both only possible to work with data that actually is given to you.
But saying "Memory and PCIe are not RF links where you waste capacity" is really um, not a great sign of insight here, imho.

@nprofile1q... why do you think DDR controllers do link training? That's a noisy RF link with reflections! Of course you need to treat it like that to squeeze out the last bit of performance to get a 3600 MHz clock rate going over stupid FR4 in a bunch of narrowly routed microstrip lines (not even "proper" transmission lines!).
I honestly think you're way deep in denial here how ubiquitous "parameters that nobody but a very narrow group of experts can understand" are.
You might be one of the experts,

@nprofile1q...
> Memory, PCIe, etc. are not RF links where you have to fully utilize your channel bandwidth/link budget and waste efficiency by not doing so.

You're, as you noted above, are very wrong about that! How do you *think* PCIe works *at all* at 2.5 GT/s over a transmission line? It's a noisy RF link. PCIe 5.0 with 32 GT/s: That literally uses FEC extensively as you'd find in a wireless RF link. To cite the PCI-SIG: "We're better off retrying a packet with 10⁻⁶ (or 10⁻⁵) prob.…"!

@nprofile1q...
> Memory shouldn't have errors, ever. It's an emergency feature, nothing more.

Assuming this is about modern server RAM in well-cooled servers: hm, that's an expensive stance to take. But OK, your time might be worth more than RAM.

Assuming this about any other kind of memory, be it flash mass media, hard drives, optical media or tape: you're nowhere close to guessing how deep ECC needs to go to make any of these technologies usable at all.

@nprofile1q... yes, absolutely, and that's fine. Now, your "trained eye", however, knows the parameters to look for. And the vendor's "trained dev" knows which parameters to display at all (which often is also a tradeoff with complexity and power). So, it's "you're not close to the truth here" all the way down, you just, and I get that desire fully, want to get the proven-to-be-useful information that you *might* use for anomaly detection.

@nprofile1q... respectfully: God, no!
If your error-corrected link *never* produces an error, you're underutilizing it, or it was badly designed and wastes capacity on pointless robustness. (The point of ECC RAM is that you *can* correct memory issues. Otherwise it'd be "checksum RAM"; the point of PCIe transaction failure modes is that you *can* retransmit.)
Your shiny server SSD? Thousands to millions of bit errors that get corrected in operation. That's the way things work. Links and media are…