cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
diegoros
Visitor
Visitor
7,968 Views
Registered: ‎06-22-2016

Bitslices?

Hello

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?

 

Thanks!

0 Kudos
7 Replies
mpiazza
Xilinx Employee
Xilinx Employee
7,936 Views
Registered: ‎11-13-2014

Hi @diegoros

 

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.

 

forum_bisc.PNG

 

 

 

 

 

 

 

diegoros
Visitor
Visitor
7,902 Views
Registered: ‎06-22-2016

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)?

 

Thanks!

0 Kudos
mpiazza
Xilinx Employee
Xilinx Employee
7,872 Views
Registered: ‎11-13-2014

Hi @diegoros,

 

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".

 

 bank_forum.PNG

 

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. 

 

byte_group.PNG

 

edit:  Add user tag to top of post.

diegoros
Visitor
Visitor
7,566 Views
Registered: ‎06-22-2016

Hello

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?

 

Thanks!!

0 Kudos
sandrao
Community Manager
Community Manager
7,501 Views
Registered: ‎08-08-2007

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. 

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
0 Kudos
sandrao
Community Manager
Community Manager
7,500 Views
Registered: ‎08-08-2007

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

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
kjstephen
Visitor
Visitor
7,262 Views
Registered: ‎05-23-2017

Hi,

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?

0 Kudos