[Router] Fix shim tile connections for non-DMA/NOC ports

[Yu-Zhewen]

This fix addresses an issue in the shim tile circuit flow for non-DMA/NOC ports. Previously, the router was producing incorrect connections in the generated switchbox configuration.

For a shim tile circuit flow defined as:

aie.flow(%t00, CTRL : 0, %t00, SOUTH : 0)

The router incorrectly generated:

aie.switchbox(%t00) {
  aie.connect<SOUTH : 0, SOUTH : 0>
}

Instead, the correct output should be:

aie.switchbox(%t00) {
  aie.connect<CTRL : 0, SOUTH : 0>
}

A new router unit test has been added to validate this behavior.

[Yu-Zhewen]

This new unit test also demonstrates the preconfigured control packet routes.

The plan is to automate the generation of these routes in an AMDAIE pass, which will be addressed in a separate PR.

reference: Xilinx/mlir-aie#1705

[jtuyls]

LGTM. Just one small question and one nit.

[jtuyls]

This would be for the control response right?

[Yu-Zhewen]

Xilinx/mlir-aie#1705 introduces a new pass to automatically insert the following two groups of flows:

(1) shim-DMA-to-tile-CTRL, handles sending control packets into each tile.

(2) tile-CTRL-to-shim-SOUTH, which is not specific for control packets, but instead to receive any TCT for DMA BD. This was previously handled by a hack in CDO generation, and mlir-aie relocates this feature into the new pass.

(we currently still have this hack)

iree-amd-aie/runtime/src/iree-amd-aie/aie_runtime/iree_aie_configure.cc

Lines 270 to 279 in 332e8d1

	// FIXME hack for TCT routing
	// TODO copy-pasted: Support both channels
	// TODO(max): find a way to keep track so that multiple calls don't
	// rewrite/overwrite with same data.
	if (tileLoc.row == 0) {
	auto slvPortNum = 0;
	auto mstrPortNum = 0;
	TRY_XAIE_API_LOGICAL_RESULT(XAie_StrmConnCctEnable, devInst, tileLoc, CTRL,
	slvPortNum, SOUTH, mstrPortNum);
	}

---

There is also a possibility if we want to retrieve data from CTRL port, then we need to set up tile-CTRL-to-shim-DMA instead of tile-CTRL-to-shim-SOUTH. This is currently not covered by Xilinx/mlir-aie#1705, but an example has been provided to do so manually.

https://github.com/Xilinx/mlir-aie/blob/30300fadd08e0a6189f1f493ada7948d99241034/test/npu-xrt/add_one_ctrl_packet/aie.mlir#L32

[jtuyls]

I see, this makes sense, thanks for the explanation! Are you intending to get rid of that hack as part of this control packet effort?

[Yu-Zhewen]

Yes, I am currently working on a PR based on Xilinx/mlir-aie#1705, where I will also remove that hack

[jtuyls]

Could you add a comment here to explain in which cases this special connectivity is is needed in which not?

[Yu-Zhewen]

done