Hey all! I realize this is a slightly mis-targeted question (why not just ask Xilinx? I did, and got no response...), but hopefully there's enough knowledge of how the NIC-400 works here to help me get to some understanding.
In the Zynq UltraScale+, the three ports that connect the PS to the PL have an ID width of 16 bits. The design these are connected to in the PL is having trouble meeting timing with the interconnect it's using with such a large ID width, so I'm trying to figure out which of these bits I can fix as constant given the access patterns and behavior of the ARM cores communicating with the PL.
Based on the Zynq TRM, I was able to determine that bits [9:2] can be fixed given that they represent accesses coming from the APU cluster of four A53 cores (with bits [1:0] indicating which core in the cluster), but the remaining six bits of the ID are still opaque to me.
The NIC-400 documentation specifies that these bits are used to route transactions through the interconnect (obviously!), and that the actual mapping of them is set up when configuring the IP. I do not have access to the NIC-400 IP source or tooling used to configure it, but I do have an image of the full layout of the interconnect, which I'm hoping that someone with access to this tooling can use to give me some hints about which bits I can safely tie down (and to which values) inside my PL design. The accesses that are made to the PL port in question (M_AXI_HPM1_FPD) only ever come from a single source (the APU MPCore), and I've indicated their path with large blue arrows in the image below.
Based on that image and doing some rough counting of input ports and how everything connects six bits seems like it would be enough to fully specify the path from a transaction's source to the M_AXI_HPM[0,1]_FPD ports, but how they're actually specified I have no idea. There may be additional information I can source from the ZynqMP's documented register set for the FPD Main Switch and CCI (transaction prioritization, QoS, etc.), but many of those registers are only documented to exist and have very little additional context.
I would love to be able to fix bits [15:2] of the ID in the PL design, since all transactions to the M_AXI_HPM1_FPD port always come from the APU MPCore and should always take the same path through the interconnect. If there is simply no way to know what the interconnect routing bits are based on that image (and the fact that the FPD Main Switch ports aren't named leads me to believe that it might be), I could always just have the very first transaction I receive after reset on that port record those bits of the ID and force the unknown bits of the response IDs to be the same. Bit of a hack, but unless someone has additional information that implies that the bits might not be constant, it might have to do!