catlass-hardware-constraints

Start with layout-based defaults such as (128, 256, 256) for RowMajor A and B, then verify capacity with the budget formulas. Keep m0=m1 and n0=n1, set k0 around k1/4, and confirm every buffer stays within its limit before compiling.

Static_assert failures after TileShape edits usually mean a buffer budget was exceeded. Recompute L1, L0A, L0B, and L0C usage with the element-count formulas, accounting for element width and the Pingpong double-buffering factor of two.

On Atlas A2, L1 is 512KB for A/B tile double buffering, L0A and L0B are 64KB each, and L0C is 128KB for fp32 accumulation. Other generations like Atlas A5 may differ, so verify against the current ArchTag documentation.

Yes. With fp32 inputs, L1 A/B tiles are counted at 4 bytes per element, so k1 or m1/n1 often must be reduced to stay under the 512KB L1 limit. L0C accumulation typically remains fp32 in both cases.

RowMajor kernels generally require the inner axis to be 512B aligned, roughly 256 fp16 elements per row. If the shape is unaligned, use padding-aware kernel variants or extend shapes with padding semantics rather than forcing tile changes on an incompatible kernel.