ContributionsMost RecentMost LikesSolutionsRe: clarifications about Sync Header positions getting changed after 128b/130b block in pcie Hi VenTingT, I have not encountered this issue. but I want to verify it as the scenario is specified in pcie gen6 specification docuement. Thanks Srilakshmi Re: clarifications about Sync Header positions getting changed after 128b/130b block in pcie Hi Ven Ting, Thanks for information. could you please let me know whether sync header positions can be changed because of PHY that is whether they can occure in bit positions 1 and 2 rather than in positions 0 and 1 as described above. although they are generated in MAC whether that shifting can happen because of PHY . Thanks Srilakshmi clarifications about Sync Header positions getting changed after 128b/130b block in pcie Hi , I am using the below specification document. PHY Interface for the PCI Express*, SATA, USB 3.2, DisplayPort*, and USB4* Architectures January 2023 Revision 6.2 we are using serdes architecture for pcie. Could you please clairfy the following. with 128b/130b encoding, a block is 130 bits in length., Sync Headers are expected in bits 0 and 1 and the block ends with bit 129. This is the expected alignment for all received blocks.If the Receiver receives an EIEOS where the Sync Header appears in bits 2 and 3 rather than bits 0 and 1, then the Receiver must change its alignment such that the Sync Header appears in bits 0 and 1 once again. could you please provide the clarifications in which scenario mac will receive Sync Header in bit position 2 and 3 . instead of bit position 0 and 1. Re: whether txdatavalid signal should be drivien by mac as 1 or 0 in pcie serdes architecture mode. Hi Ven Ting_Intel, Thank You providing the clarifications. I am referring Revision 6.2 of PHY Interface for the PCI Express*, SATA, USB 3.2, DisplayPort*, and USB4* Architectures. it is also mentioned that TxDataValid :: PCI Express mode and SATA mode and USB mode (original PIPE-only): I think they mean we no need to take care of TxDataValid which can mean 0 or 1 also. Could you please clarify about it why we need to drive TxDataValid to 1. Thanks Srilakshmi whether txdatavalid signal should be drivien by mac as 1 or 0 in pcie serdes architecture mode. Could you please clarify whether txdatavalid signal should be drivien by mac as 1 or 0 to phy in pcie serdes architecture mode. as pipe specification 5.1 , architecture diagram 4.2 has also txdatavalid signal . but later in specification it is mentioned that the signal is applicable only in original architecture mode. Solved