Forum Discussion
I’m not following the problem with bitslip. When using DPA, you need to bitslip each channel independently and have a known pattern on each channel to detect the word boundary. The DPA behavior can lead to any 2 channels being a bit apart in the word alignment. When not using DPA, it is common to use the same bit slip pulse for all of the channels since every channel uses the same capture clock. There must be reasonably low channel to channel skew in the PCB layout for it to work properly, but you should see data in every channel shift a bit when pulsing the bitslip port, assuming the single signal has been wired up to all of the ports correctly.
I don’t know what we are supposed to be looking at in the signal tap capture. You said there are 8 channels, but the data is grouped in 12 bit chunks and we don’t know the deserialization factor. You need a description for what each signal represents, and I find it’s helpful when debugging the LVDS IP to have at least one of the groups expanded so you can see what is happening for each channel. You should see the data shift in the direction of MSB to LSB one bit for each bitslip pulse:
Hello Aqid,
Yes, the SignalTap doesn't show the detail of my issue of bitslip. Actually, my question is about the signal bus "rx_bitslip_ctrl(7..0)". As I indicated, this bus's every bit is assigned with same value from "bitslip_pulse". However, it only changed from "0000 0000" to "0000 0001", instead of "1111 1111". That's my primary question, why not all rx_bitslip_ctrl bus bits are assigned with bitslip_pulse?
Or, as you said, Quartus can automatically force only LSB to accept my assignment, and ignore other bits assignment?