05-09-2017 07:13 AM
We are migrating our designs from Virtex 7 to Virtex Ultrascale and we started seeing these errors
ERROR: [DRC 23-20] Rule violation (PDRC-203) BITSLICE0 not available during BISC
I see that we can apply workarounds to avoid this error, but I'm still failing to understand the concept of bitslices. Does every pin has a corresponding bitslice? Or there's a bitslice for every group of pins? And is this bitslice0 constantly doing self calibration?
05-09-2017 02:06 PM
The BITSLICE is a relatively new device primitive that we introduced with UltraScale, to give a quick summary you could think of it as the IOSERDES, IODELAY and a FIFO wrapped up into one primitive, but the key thing is that there is a lot of dedicated routing between all of these components that make up the BITSLICE which helps improve performance and so it warrants a new primitive.
When you're working in this mode with the BITSLICE we call this "Native Mode". If you wanted to get the full technical details, I would recommend taking a look at the "Native Primitives" section of UG571 (page 197).
When you instantiate "just" an ISERDESE3 in UltraScale, the tools will configure all of this in such a way that it acts like an ISERDES, and/or IDELAY. We call this mode "component mode" now.
Okay -- so touching on why you see the DRC and your questions on calibration, there is a great diagram in the UltraScale SelectIO User Guide (UG571) that shows how the BISC calibration occurs (below).
If you look in the diagram there is literally a mux that sits between the input buffer and the "Input Delay Line" (aka IDELAY) and during the calibration, the input to the IDELAY is muxed away from the regular input clock signal and is replaced with the capture clock which then allows the delay line to be tuned such that the capture clock is centered in the data eye.
Of course, when the input is muxed over to the capture clock to perform this calibration, the input will not be available and any signal input to the IBUF(DS) won't be captured until the mux is switched back when calibration completes.
05-10-2017 06:08 AM
That is very interesting. Thank you so much for the detailed answer.
Now I have another question. I am receiving this BITSLICE0 error in multiple pins. Does that mean that there is more than one BITSLICE0 (like in groups of bitslices)?
05-10-2017 01:25 PM - edited 05-10-2017 01:26 PM
Yes that is correct, for UltraScale each I/O bank is divided up into four "Byte Groups" and each of these four byte groups contains two BITSLICE_0's.
Just as in 7-series each IOB has a ILOGIC/OLOGIC pair with the ISERDES/OSERDES, each IOB in UltraScale has a BITSLICE. (Note that this is for High-Performance and High-Range banks, High-Density banks that you'll find on some devices are a different story)
For example, here's a diagram from UG571 showing the general layout of an I/O bank in UltraScale. As you can see each I/O bank has fifty-two IOB's and each of those fifty-two IOB's are then grouped into four smaller groups of thirteen IOB's known as a "Byte Group", you could think of this like a "sub-bank".
If you zoom into to more detail on one of those four "byte groups" you can see that each byte group is then further sub-divided into two "nibbles", with the lower nibble having six of the thirteen IOB's and the upper nibble having seven of the thirteen IOB's and each one of these nibbles has a BITSLICE_0.
edit: Add user tag to top of post.
05-16-2017 08:25 AM
Thanks again for such a detailed response.
One more question. Is it possible to use the I/O corresponding of a Bitslice0 as regular I/O (not for high speed communication)? If so, will BISC still occur? Or is there a property that disables this?
05-17-2017 11:59 PM
You can use the I/O as either BITSLICE (Native mode) or as ISERDES/OSERDES component mode. If you are in component mode if you use the IDELAY/ODELAY in TIME mode then BISC will be used. There is the EN_VTC port on the delay blocks.
05-18-2017 12:00 AM
Also you can mix Native and Component in the same nibble, there is a section Mixing Native and Non-Native Mode I/O in a Nibble in the UG571
05-23-2017 06:23 PM
I have a question that is related to the bitslices - the "IDELAY" function.
Our system has 8 RX-only channels that a single centered DDR clock, all placed in byte-groups 2 and 3, the clock in bitslice 0.
We're using the HSSIO Wizard v3.1 to set it up, selected Rx Delay Mode TIME, Delay Type FIXED.
I was curious to see what actually happens with the BISC, and what values does it actually assign to the 8 channels after the initial calibration. So I made a special build with the Delay Type set to VAR LOAD so the actual IDELAY tap counts could be brought out for observation.
Sure enough, we found that the BISC assigned a range of "align_delay" tap counts to the 8 channels just as described in UG571. We put the board in a temperature chamber and tried the BISC at high and low temperatures, and as expected, the initial delays that the BISC calculated would change. Longer delays at high temperature, shorter at low temperature, and quite consistent over several trials.
My question is this: Does the VTC tracking function actually adjust the IDELAY tap counts during operation to compensate for voltage/temperature variations, or is it a one-time calibration at start-up?
If we calibrate at low temp, then raise the temp while observing the tap counts, should the observed counts change to track the temperature?
We are seeing that the counts do not change. Whatever the BISC initially sets, there it stays. But if we restart the BISC at a different temperature, it will find new values.
The VTC control inputs are set to 1 at each bitslice so the VTC function should be on, or at least we think it is.
Is this what it is supposed to do, or are we doing something wrong?