Model XFRDMA / PSI-L thread bridge and its ready/stall semantics

[pratheesh]

Correction (see the comment below): the ID map in "Requested scope" is wrong.
XID is block-local, so the real map is 0x50 = PSI-L status, 0x51/0x52/0x53
= threads 1/2/3 - three threads, not four - and global device ID 0 remains the
MPY/MAC accelerator. Status is also two words (Table 6-108), not one.
Please implement against the corrected map, not the text below.

Gap

The XFRDMA/PSI-L bridge is absent. Its XFR device IDs are currently accepted
by the parser but have no model, so data is silently zeroed or dropped.

Requested scope

Model the first useful XFRDMA slice from AM64x/AM243x TRM SPRUIM2J section
6.4.6.3.2:

• status ID 0 exposes rx_ready[3:0] and tx_ready[3:0];
• IDs 0x50..0x53 address PSI-L threads 0..3;
• receive reads consume an injected packet FIFO; transmit writes enqueue a
  packet; full TX has the documented core-stall behavior;
• preserve thread separation and provide deterministic test injection/drain
  APIs.

The shared IDs 0x58/0x59 and wider thread count can follow after this
minimal four-thread oracle has tests.

Acceptance

Green vectors cover RX readiness, RX consumption, TX enqueue, a full-TX
stall, and no cross-thread leakage. This is simulator evidence only; it does
not assert PSI-L fabric timing or hardware validation.

[pratheesh]

Correction to the requested scope above

The device-ID map in the original description is wrong, and I want to correct it
before anyone implements against it.

I wrote "status ID 0 exposes rx_ready[3:0] and tx_ready[3:0]; IDs 0x50..0x53
address PSI-L threads 0..3". That reads the XID as a global broadside ID. It is
block-local.

Per SPRUIM2J:

• Table 6-60 (Hardware Module Broadside ID Mapping) lists
  XFR2PSI 0x50/0x51/0x52/0x53, i.e. the block occupies those four global IDs.
• §6.4.6.3.2.1: "The XID to the XFRDMA block is used to select the PSI-L thread
  to access. For example XFRDMA block XID 1 is for the first thread, and XID N is
  for the N-th thread."
• §6.4.6.3.2.1.1: "The XFRDMA block uses XID 0 to read status of the PSI-L bus."

So base 0x50 + block-local XID gives:

global ID	block-local XID	function
0x50	0	PSI-L bus status
0x51	1	PSI-L thread 1
0x52	2	PSI-L thread 2
0x53	3	PSI-L thread 3

Three threads, not four, and global device ID 0 belongs to the MPY/MAC
accelerator (Table 6-84), not to XFRDMA. The block-local reading is also the only
self-consistent one: a global XID would collide with MAC (0), CRC (1) and the
scratchpads (10/11/12).

Two more corrections to the acceptance criteria while I am here, both found by
reviewing an implementation written against the wording above:

1. Status is two words, not one. Table 6-108: word 0 is rx_ready[3:0], word 1
   is tx_ready[3:0]. An implementation that packs both into word 0 will let
   TRM-conformant firmware read tx_ready from word 1, get zero, and block forever.
2. The full-TX behaviour is a stall, not a retry. An implementation that models
   it by rewinding the program counter re-executes the instruction, so any side
   effect that already committed — an XCHG pops the RX FIFO before it can know the
   TX side is full — replays and destroys received data. The acceptance vector should
   assert that the RX depth is unchanged across the stalled steps, not only that
   the PC did not advance.

Filed against my own issue text; no implementation has been proposed on it yet.