bugs for the GetWriteToSNDone() check in ProcessResp_SN

Hi sir,
I found there may a bug in the ProcessResp_SN @L2663,
because SetWriteToSNDone is called in two place:
1. req->SetWriteToSNDone(true); @L2653
2. req->SetWriteToSNDone(true); @L2694 which will never be called, because the code only run to L2694 when the return value of GetWriteToSNDone() is already true !

so the condition @ L2663 can only be true because the code ran to L2653 ever

but the code can only run to L2653 when the Comp from SN has already received which is when both condition below are true

1. (rsp.IsCompDBIDResp() || rsp.IsDBIDResp()) @L2609
2. (rsp.IsCompDBIDResp() || req->GetCompSNReceived()) @ L2622

so when the Comp from RN aready is reveived by INC, it will never be reveived again , so the branch if (req->GetWriteToSNDone()) @L2663 seems useless ！

https://github.com/Xilinx/libsystemctlm-soc/blob/42aa8ed780cb9eef3a61bc50ea35ff079a7e6284/tlm-modules/iconnect-chi.h#L2663

Start in tlm-modules/iconnect-chi.h at ProcessResp_SN and inspect the linked lines around 2609, 2622, 2653, 2663, and 2694. Trace the conditions that set and check GetWriteToSNDone(), then look for relevant callers or tests. Done means the control flow is confirmed and the issue's suspected unreachable branch or condition has an agreed, verified resolution.