[WIP] DRTIO Aux Overhaul

[Spaqin]

ARTIQ Pull Request

Description of Changes

DRTIO Aux protocol has been a simple one which has been enough up to ARTIQ-7. However with ARTIQ-8 we're introducing subkernels and distributed DMA, which in turn requires asynchronous message passing from satellite to master and between satellites. That has been hacked with a flag in the main DRTIO protocol - which was enough to get it working, but it could've taken precious RTIO space. An overhaul to extend the capabilities of the protocol was long overdue.

Since it's a topic that required a fair bit of design work, I have written more about the old protocol and proposed solution here:

drtioaux_overhaul.md

For a TLDR, the new protocol:

• extends the original idea of transactions (request -> response), and keeps track of them so multiple can be happening at a time,
• makes sure a packet is sent at least once and relies on acknowledgements to make sure it arrived safely.

The PR is marked as WIP, as the implementation currently runs on both master and satellite (link can be established, destination status reported), but is still flawed and crashes (a thread safe solution for managing transactions is necessary) and hasn't been deeply tested yet.

Related Issue

2302

Type of Changes

	Type
✓	:hammer: Refactoring

Steps (Choose relevant, delete irrelevant before submitting)

All Pull Requests

• [x] Use correct spelling and grammar.

Code Changes

• [ ] Test your changes or have someone test them. Mention what was tested and how.
• [x] Add and check docstrings and comments

Git Logistics

• [x] Split your contribution into logically separate changes (git rebase --interactive). Merge/squash/fixup commits that just fix or amend previous commits. Remove unintended changes & cleanup. See tutorial.

• [x] Write short & meaningful commit messages. Review each commit for messages (git show). Format:

  topic: description. < 50 characters total.
  
  Longer description. < 70 characters per line

Licensing

See copyright & licensing for more info. ARTIQ files that do not contain a license header are copyrighted by M-Labs Limited and are licensed under LGPLv3+.

[sbourdeauducq]

The retransmit stuff (Req 2) sounds a bit complicated, error-prone, and potentially inefficient. Would it be simpler to make the gateware able to buffer multiple packets instead? Eventually nodes will stop transmitting when they don't receive replies, so a finite buffer size should solve the issue.

[sbourdeauducq]

NB: in tests I did many years ago with Ethernet, there was a big performance/reliability difference between a naive MAC able to buffer only one packet (as is the case with drtioaux now) and one that can buffer two. And there's plenty of FPGA block-RAM usable to buffer a few packets.

[Spaqin]

Will do a less complex overhaul with multiple buffers instead of this. It probably would've worked, but would take a lot of time to polish and squash any bugs to make it truly reliable, while a simpler solution may suffice for now.