03-16-2014 10:51 AM
I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.
I have included a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair. This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. VHDL file is attached.
Simulation waveforms (also attached since image seems to be downsampled inline):
The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1].
From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.
The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this.
I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).
In my case, I have no training pattern and hance can't find the right alignment with bitslip operations. In my case, for the serial data, clkdiv is equal to the frame clock. From the simulation I can of course determine how the frame is placed in the serial data, and fix the paralell words in custom logic, but then I need to understand why I get this particular offset, and be convinced that I will always get exactly this particular offset.
I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.
Thanks in advance,
03-28-2014 08:54 AM
It's unfortunate that Xlinx hasn't been able to reply regarding this; the documentation in this case really is incomplete.
However, I have come to the conclusion that there is no good way to use the primitive without a training pattern (not available in my case) and dynamically finding the frame alignment after each startup.
A possible workaround would be to deserialise my frame clock in an ISERDES as well, and trust the two ISERDES to deserialise in phase. Then the deserialised clock would help me re-align the frame by applying bitslips.
However, I chose to do my own deserialiser in logic instead.
04-23-2014 07:47 AM
Right now I'm dealing with a similar problem that carwer is commenting. I wonder if anyone could give some light on this matter...
04-23-2014 07:54 AM
04-23-2014 08:02 AM
hi, I have used iserdes2 in spartan6 device.UG381 states details about spartan6 iserdes.I think it is similar to iserdes in 7 series FPGA.
04-24-2014 07:33 AM
Thanks for answering!!
I'm trying to deserialize a LVDS signal into a 10-bit bus using 2 iserdes in DDR mode and I'm facing several problems... one of them is exactly the same you mentioned on the first post... I can't understand the exact behavior of the iserdes and how it's getting the offset to perform de deserialization function.
I fix this problem in simulation with some custom logic, and inserting two "dead" cycles of clkdiv between each set of serial data but I'm afraid that this don't work on real hardware and chipscope shows a different behavior.
There isn't a fixed relation between the time when the parallel output comes out with the serial input, neither with clocks... as carwer metionated. Besides I don't have training pattern so I can't use the bitslip function.
You can see what I mean on the next waveforms, the two first from simulation, the last from chiscope (also in attachment):
I'm running without options... so any help or suggestion will be very appreciate.
In addition... carwer, I'm very interested in the bug you are commenting, can you tell me more about it and give some clue about how to fix it?
Thanks in advance!
PS: sorry for the length of the post!!
04-24-2014 08:02 AM
yes, apparently you have, in simulation, an undesired offset of 5 bits on the output words.
> inserting two "dead" cycles of clkdiv between each set of serial data
I don't really get what you mean by the above. However, the parallell output will be delayed some 1-2 clkdiv cycles because of internal pipelineing/registering. This depends on the attributes (generics) you set when instantiating the ISERDES. (You don't need to add any "empty" cycles of serial data.) If you have more questions on this, please also post the HDL of the instantiation.
The general answer to your concerns is that the ISERDES is intended to be used with a training pattern, and it's hence hard to use it without one. There's not a word about this in the documentation. The problem is that there is no defined behaviour on the frame alignment other than it being offsetted by bitslip operations (although the documentation suggests otherwise) so without training pattern and bitslip it's hard.
It's possible it can be done however (see https://groups.google.com/forum/#!topic/comp.arch.fpga/2xCQbx_COk0). If all ISERDES units within an FPGA will have frame alignment in phase (which is quiet possible, but not implied by the documentation, so it's hard to know for sure), then you could have an additional ISERDES de-serializing your clkdiv. Compare the output to an un-offsetted de-serialized clkdiv (1111100000), and apply bitslip to both ISERDES until you get that pattern.
About the simulation primitive bug: the workaround is to keep the input ports high not only on the rising clock edge, but for some additional time. Anything that gets you beyond the simulation delta of the flank is enough, hence I recommend adding your simulation resolution (eg 1ps). This is a concern for the control input signals, not for the serial input data; the middle of the serial data eye should be aligned to the edges of clk, and it is in your case as well (at least in the simulations).
04-18-2015 02:05 PM
While I'm not a fan of Xilinx documentation -- particularly as it relates to SERDES -- I think your assessment of the documentation is a little too harsh. For example, XAPP524, XAPP1064, and others have enough information to answer your question, although not in a particularly easy to understand format.
I hope I've read your posts carefully enough -- maybe not, and if what I write below is already obvious, forgive me.
The problem with deserialization is that the FPGA receives a serial stream of bits with no information about where words start or stop. Without additional information there is no way to deserialize the data correctly. Your idea of comparing two ISERDES blocks will only ensure that they both do the same thing, but not that they are correct. To frame the received data correctly you do need *some* kind of training pattern. But this does not have to be an explicit training pattern present in the data. A common technique is to use an additional signal provided by the source that has a known relationship to the data, and then to use this as a training pattern for all the data. An example is what is done with the type of ADCs that have a bit clock (DCO) and a frame clock (FCO), where the frame clock is known to be aligned with some data bit (like the LSB or MSB). If you run FCO into an ISERDES block, you can use that parallel output as a training pattern to generate bitslip signals. Those bitslip signals are then applied to the data ISERDES also - THE ASSUMPTION BEING THAT THE DATA ISERDES AND THE FCO ISERDES WILL DO EXACTLY THE SAME THING. Once FCO is deserialized correctly, in theory the data will be, too. Note that this is only true if you are careful that all the ISERDES are reset identically (i.e., come out of reset at exactly the same time). You also have to worry about clock distribution and input delays, but those details are beyond what I think you're asking about. (An additional consideration in the 7-series parts when using inputs spread over several banks is that the combination of BUFRMCE/BUFIO/BUFR has to be reset carefully to avoid getting CLKDIVs out of phase).
So as long as you have a framing clock in addition to the data you can avoid a training pattern in the data. I realize a lot of time has passed since the original post, but perhaps this will be useful to someone else.
01-19-2018 09:25 AM
In my case also the sampling is started after the 2 cycles of high speed clock with respect to posedge of clk_div, this gives the parellel output Q1 to Q8. This bemusing me to understand the iserdese2 block when i simulate the iserdese2 block separately.