[ttl] Use receiver-authored SRAM address tables for scalable PipeNet collectives(#620)

[brnorris03]

Problem description

PR #614 makes PipeNet transfers correct by using receiver-posted destination DFB addresses, but the physical pipe synchronization layout still uses hardware semaphore ids for resources that do not need to be local semaphores. Address publication is data storage, not synchronization, and sender-ready counts need to scale with PipeNet pipe count rather than the local semaphore-id budget.

This matters because the per-pipe layout can exceed the TT hardware semaphore limit (#619). Uniform collective transfers also need a clear correctness boundary: until per-receiver destination addresses are represented (#617), collective receivers must publish equivalent destination DFB addresses.

What's changed

TLDR: This PR separates PipeNet address storage from synchronization, makes the compiler emit the physical pipe resource plan, and uses GlobalSemaphore-backed sender-ready counters when local semaphore ids are not sufficient. Receiver posts publish actual destination DFB addresses into source-core SRAM address tables, receivers increment a counted ready object, and senders consume the receiver-authored address after the ready count is satisfied.

In addition, pre-TTKernel compiler abstractions now use point-to-point and collective terminology for semantic pipe transfer contracts, instead of using unicast and multicast for user-level semantics. A Pipe defines a transfer relation from one source participant to one or more receiver participants. That transfer relation has a contract independent of how it is lowered:

• point_to_point: exactly one source participant and exactly one receiver participant.
• collective: one source participant and a receiver set participating in one transfer contract.

The lowering decision, such as a point-to-point NOC write versus a hardware multicast write, is a TTKernel-level implementation detail that can depend on the transfer contract, receiver count, hardware capabilities, and later cost-model decisions.

Details

• Pipe synchronization previously used hardware semaphore ids for both mailbox storage and synchronization. Address publication now uses compiler-managed source-core SRAM address tables, while ready counting and completion waits are represented as separate resources.
• Source-in-destination uniform collective transfer previously used the posted-address mailbox protocol. It now uses aggregate ready counting: each receiver contributes to one ready count, the sender waits for the receiver count, and the sender reads one receiver-authored DFB address from its source-core address table.
• Non-loopback collective transfer previously either needed the posted-address mailbox protocol or required the sender to reconstruct receiver DFB state. Receivers now publish their DFB address directly into the sender's SRAM address table with an inline 32-bit NOC write, so non-loopback uniform collective transfer uses the same aggregate ready counting protocol.
• Sender-ready counting previously consumed one local semaphore id per source-local pipe. Ready counters are now selected by the compiler resource plan, with GlobalSemaphore-backed counters used for scalable layouts.
• C++ lowering and Python host allocation previously maintained parallel resource estimates. The compiler now emits the pipe resource plan that specifies local semaphore descriptors, GlobalSemaphore descriptors, SRAM address-table allocations, and runtime argument positions.
• Collective receive posts previously allowed the same logical pipe to publish different destination DFB addresses. PipeGraph now validates receiver DFB index, DFB type, and static destination tile offset before lowering; non-uniform or untraceable collective destination addresses emit a diagnostic citing Support per-destination pipe receive addresses for multicast lowering #617.
• Transfer contract was previously inferred only from destination extent. The frontend now preserves the collective contract on ttl.create_pipe, so a slice-origin collective transfer covering one receiver still uses collective ready-counting layout.
• Pre-TTKernel code previously used unicast and multicast for semantic pipe contracts, which made the user-level contract easy to confuse with hardware multicast lowering. Frontend and compiler wording now use point-to-point and collective transfer contracts; legacy is_unicast / is_multicast accessors remain as deprecated aliases, while TTKernel and profiler code keep hardware multicast terminology.
• Semaphore over-allocation previously reached TTKernel emission, where it could request invalid semaphore ids. Pipe synchronization resource allocation now reports a deterministic error before TTKernel emission when no valid physical allocation is available.
• TTKernel previously exposed only semaphore-style remote writes, not a general remote 32-bit L1 write for receiver-authored address publication. The tt-mlir submodule now includes ttkernel.noc_inline_dw_write, which lowers to noc_inline_dw_write<InlineWriteDst::L1>.
• Aggregate ready counting and GlobalSemaphore-backed ready counters remove semaphore growth from collective receiver count and source-local pipe count for per-device PipeNets, including SPMD mesh execution where the same intra-chip PipeNet runs on each shard. They do not add inter-chip PipeNets or receiver DFB slot reuse; full-device all-to-all patterns with more overlapping arrivals than the supported DFB block count still need batched/phased DFB reuse after explicit pipe transfer IR.

Tests

• Aggregate ready counting pytests cover loopback collective transfers, full-grid fanout, non-loopback address-table publication, degenerate slice-origin collective transfers, row all-to-all collective transfers, 2D all-to-all collective transfers, and the many-PipeNet semaphore-limit regression.
• GlobalSemaphore resource tests cover source-local pipe counts that exceed local semaphore capacity, interleaved PipeNets, and full-launch-grid point-to-point fanout at the GlobalSemaphore threshold.
• Negative pytest coverage checks non-uniform collective destination addresses, impossible physical resource allocations, and the depth-1 protocol case that requires phased pipe transfer lowering (PipeNet phased channel lowering for repeated sends on one logical channel #623).
• Python-only PipeNet resource model tests cover degenerate collective transfers, non-loopback address-table allocation, overlapping source-local pipes, GlobalSemaphore ready counters, and large 2D all-to-all resource scaling.
• Host-side runner unit tests cover GlobalSemaphore allocation, explicit device selection, tensor-derived device selection, zero-count allocation, and missing-device diagnostics.
• MLIR lit tests cover aggregate send/receive lowering, non-loopback address-table lowering, resource-plan emission, GlobalSemaphore-ready lowering, degenerate collective metadata, dynamic/untraceable collective receive offsets, invalid collective metadata, and deterministic resource diagnostics.
• Python lit coverage includes the issue PipeNet dual delivery-path reproducer deadlocks when both routes are enabled #625 liveness-based resource allocation reproducer, which exercises the combined row/column/helper PipeNet schedule on an 8x7 launch grid and verifies successful device synchronization.

Stacked PR sequence

Pipe compilation work required to match Blaze's scalable communication model: GlobalSemaphore-backed counting, explicit L1 address/state, DFB lifetime allocation, and batching where storage is limiting.

#	PR	Status	Main problem solved
1	#614	Base PR	Makes PipeNet transfers correct by switching to receiver-posted destination DFB addresses. This removes sender inference of receiver DFB write-pointer state, but not semaphore pressure.
2	#622	Current PR	Removes collective receiver-count and source-local pipe-count semaphore growth by using receiver-authored SRAM address tables, compiler-emitted pipe resource plans, and GlobalSemaphore-backed ready counters. This eliminates the local semaphore-id scaling limit for large uniform collective transfers.
3	#624	Follow-up PR	Represents transfer phase, receiver-authored address publication, ready counting, send, and receive-token wait explicitly before control-flow-general lowering. This removes the need to infer transfer phase and queue depth from ttl.copy placement.
4	#627	Follow-up PR	Assigns source-core address-table slots and sender-ready counters from explicit pipe transfer lifetimes. This reduces those resources from logical pipe count to concurrently live same-source transfer count while keeping receiver completion per PipeNet.
5	TBD	Planned follow-up	Supports phased pipe transfer lowering for receive-ahead and pipelined loops with monotonic ready counts, finite address-table depths, and deterministic diagnostics when safe pipe transfer state cannot be allocated. This extends the current one-live-post protocol to programs where later receive posts may be live before earlier sends complete. Issue #623
6	TBD	Planned follow-up	Lowers large all-to-all into communication batches when receiver DFB capacity is smaller than the number of incoming pipes. This eliminates the simultaneous receiver DFB slot scaling limit when the program can consume batches incrementally.
7	TBD	Planned follow-up	Groups post/wait state when pipe tokens prove identical lifetime and completion behavior. This reduces duplicate pipe synchronization resources after liveness allocation exists.

Fixes #620, #625.