Global CB Support

[tt-aho]

Ticket

#14108

Problem description

Metal infra support needed for creating and dispatching global circular buffers.

What's changed

Add metal infra support for creating and dispatching global circular buffers.

• Split CB constants from circular_buffer.h to avoid building kernel file when building metal lib
• Add GlobalCircularBuffer implementation. a Global CB has 2 buffers
  • cb_buffer is the actual buffer space in L1 that is used for pushing/popping data
  • cb_config_buffer is the data needed to populate the remote cb interface when initializing/using remote cbs in kernels
  • config contains 2 arrays of ptrs (l1 aligned) used for tiles acked/sent sized based on num_receivers_per_sender
• Add a RemoteCBInterface struct, that is a union with the original CBInterface (renamed to LocalCBInterface) struct in order to save memory when creating the sized array. Each cb_id in the array corresponds to either a local or remote config, not both. We assert the two structs are the same size as we provide pointer aliases to the array to simplify access for whether it's a local/remote cb
• Add new apis/functions for initializing the remote interfaces, as well as apis to interact/use the remote cbs in a new remote_circular_buffer_api.h file taken from the original remote cb microbenchmarks
• Add support in dispatch for dispatching remote cb configs. Currently the config is 1 word representing the address to the config buffer to read/use
• Update cb dispatch to support dispatching remote cbs. Kernel launch msg now contains a remote cb offset, as well as the min_start_remote_cb_id.
  Dispatch data is laid out as follows:
  Local CB data from 0 to max index across all cores, followed by remote CB data from 31 to min index across all cores.
  We require that the min start remote index >= max end local index to avoid overlaps with initialization, since local cbs are sequentially initialized from 0 up, whereas remote cbs are sequentially initialized from 31 down. This also means for optimal dispatch performance, users should specify remote indices sequentially from 31, otherwise we are sending and initializing extraneous data, similarly to how local cb indices should go from 0 for optimal perf.

We decided to add the new global circular buffer support under an experimental namespace.
On the kernel side we are constrained with local memory size for the statically allocated interface array, so we cannot store as much data as we could for potentially simplifying user experience. Ex user must manually call secondary initialization functions in their own kernel, which is fairly error prone.
On the host side, we kept almost all apis the same except for a new CircularBufferConfig constructor to minimize api changes, however this may not be the best approach and potentially new apis should be added instead. TBD until we finalize some other cb api aspects regarding things such as potentially autogenerating ids.

Checklist

• Post commit CI passes https://github.com/tenstorrent/tt-metal/actions/runs/12142464308
• Blackhole Post commit (if applicable)
• Model regression CI testing passes (if applicable) https://github.com/tenstorrent/tt-metal/actions/runs/12141520196
• Device performance regression CI testing passes (if applicable)
• New/Existing tests provide coverage for changes

[yugaoTT]

when running the subdevice ops, we probably need to update the compute kernel pointers as well (inplace CB update to the Global CB pointer). I wonder should this be done within the kernel or have a better way of hiding it.

[eyonland]

I would put this directly in namespace v1. We have announced that we are no longer changing v0 going forward.

[tt-aho]

I've moved it to v1 namespace, please take another look.

[pavlejosipovic]

From conv/max_pool perspective this looks good.