Hi, I am having trouble resetting the Iserdes properly (in the serdes_v6 block). If I assert a pulse reset (1 clock cycle) the iserdes primitive will not properly initialize 90% of the time and the adc data bits get deserialized improperly. Once I have pulsed that reset the first time I can see bits getting shifted around. But if the synchronization does not happen correctly the first time pulsing the reset again will not have any affect on the bit order. The only time I can properly reset this block is if I pulse reset the clock buffer simultaneously with the iserdes block, but often times I have to do it multiple times. Using this method I can properly initialize this block 1 out of every 15 times. Obviously I am not doing something correctly. How do I reset the serdes properly so that I just need to do it only once to get it to initialize properly? Does this reset have to be held multiple clock cycles? Does something else have to be held in reset while I am resetting the Iserdes? Does bitslip play any role here?
Hello Stan, It is likely that the design is not constrained enough, or something like that. It would maybe make sense to ask Xilinx about these ISERDES story. Best Regards, Arnaud
over 2 years ago
Arnaud, I have not seen the issue running the reference bitfile that you provide. But I am using the core hardware blocks from your reference design and have added them to a larger project. The steps that I take to initialize the board are the same as yours, except for pin alignment. I am aligning the bits by enabling the ramp test pattern in the ADC and advancing the iodelays until the pattern arrives as expected. I have come across certain scenarios where after resetting the clock buffer and the iserdes block, scanning through all 64 delay taps does not align the data. If that happens, I reset the clock buffer and iserdes block again and try the taps again. I repeat this process until finally the iserdes block initializes to a proper state where I can adjust the tap delays until data is properly aligned. I don't know what the bitslip is supposed to do that is why I am asking if the bitslip affects the way the iserdes deserializes the data. The other problem is that this reset issue that I've described above seems to be happening with different builds of my firmware, which could mean it's affected by the routing during implementation.
over 2 years ago
Dear Stan, I am not sure to clearly understand, do you mean our reference design does not work fine? Or your modifications on the reference design are causing problems? Best Regards, Arnaud