1181 - Which clock do I use to sample the lsm_status*/ffs_ls_sync_status* signal in PCS/SERDES based devices? Is there a chance I could miss the lsm_status pulse if I use a 16-bit wide PCS/FPGA interface data?

1181 - Which clock do I use to sample the lsm_status*/ffs_ls_sync_status* signal in PCS/SERDES based devices? Is there a chance I could miss the lsm_status pulse if I use a 16-bit wide PCS/FPGA interface data?


In the case of  LatticeECP2M/LatticeECP3/LatticeSC/M SERDES/PCS QUADs, logic in the  Link State Machine block generates the lsm_status*/ffs_ls_sync_status* signal. This logic is synchronous to the RX recovered clock. A single stage sync flop is OK to synchronize the signal to the TX clock domain since the lsm_status signal will not have single cycle transitions in most protocols.

For example, in XAUI mode, based on Figure 48 - 7 - PCS synchronization state diagram of the 802.3ae-2002 IEEE specification, the LSM circuitry will not set lsm_status high until it has received at least 4 Comma characters.

So the lsm_status will be low for at least 4 cycles (more than that knowing that Comma columns don't typically occur back to back in a randomized A K R Idle period).

When lsm_status is high, the LSM circuitry will not set lsm_status low until it has received at least 4 consecutive  invalid characters. So the lsm_status will be high for at least 4 cycles.

Since lsm_status is high/low for more than one byte clock (or until RX lane RESET is asserted) as per the explanation above, it is not possible to miss a transition on the signal.