03-30-2010 02:15 PM
I have encountered several issues hen using the ICAP port with a Virtex-5 device. The issues are about the driver code, which has errors, and it seems it was like that in all the driver versions that supported Virtex-5 devices.
First : Getting the slice (row, column, slice ID) coordinates from the (X, Y) cooordinates
The source file xhwicap.h declares 3 macros to achieve the change of coordinates : XHwIcap_mSliceX2Col, XHwIcap_mSliceY2Row and XHwIcap_mSliceXY2Slice.
Actually those macros were written for Virtex-4 devices (4 slices of 2 4-inputs LUTs by CLB), and two formulas should be different for Virtex-5 devices.
The good code is :
#define XHwIcap_mSliceXY2Slice(SliceX,SliceY) \
( SliceX % 2 )
#define XHwIcap_mSliceY2Row(InstancePtr, SliceY) \
( (InstancePtr)->Rows - SliceY )
This was first described in the post :
Second issue : The definition of the constant structure XHI_CLB_LUT in the file xhwicap_clb_lut.h is false
The field CONTENTS is the same for the two slices L & M. It seems when the file was written a copy-paste move was not finished ? ;)
Besides the comment introducing the declaration of this constant XHI_CLB_LUT contains "Note that there are 8 16-bit LUTs" [by CLB]. Actually the LUTs are 64-bits ones, this comment is from the definition for Virtex-4 devices.
The effect of this issue is that when using the functions XHwIcap_GetClbBits and XHwIcap_SetClbBits, the same configuration bits are read/written for the slices 0 and 1. And nothing works as expected.
But there I do not have the right definition for XHI_CLB_LUT for Virtex-5 devices, and I don't even know if the field CONTENTS is for the slice 0 or the slice 1, maybe there are more errors there...
Does anyone have the correct definition ?? Can please a reader from Xilinx give it, as an answer to this post for example ?
Thanks for your answers, and I hope this message was useful for you.
And if I made any mistake in this post, please report it !!
03-31-2010 08:15 AM
xapp864 mgith be useful, as it actually works (and has been extensively tested).
There is no c code, but it does have a lot of things documented on the use of the ICAP.
The source is in the lounge, so you have to dig for it (the links are moving from an application, to supported IP).
If interested, email me directly at email@example.com, and I will send you a zip file including documentation (which ecplains a lot of how the device is organized).
03-31-2010 11:21 AM
Thanks to point out the xapp864, I read many comments about it and it seems to be a great app, I am deeply interested in seeing what we can achieve with this as a base.
Actually my work is not about SEUs (I read that xapp864 was most useful tu evaluate the reliability of the devices), but about dynamic partial reconfiguration, that is dynamic instanciation of HW modules. What I said in my first message is what I bumped into when trying to use the very interesting functionality of the HWICAP and its driver, that is reconfiguration of the LUTs.
By the way, I read this thread http://forums.xilinx.com/xlnx/board/crawl_message?board.id=GenDis&message.id=3159
As Xilinx has (internally) developped means to evaluate the FPGAs reliability, I wondered if equivalent work has been done for dynamic partial reconfiguration. Or if Xilinx had made available some documentation about this process, for example protection from short-circuits due to bad design reconfiguration, about how to switch between the two ICAPs in the Virtex-5, or "erasing" the contents of a reconfigurable slot, and many other points that are likely to change a development process.
I dug in the website xilinx.com and I have not found such information, which is extremely valuable in my case (and for everyone doing partial reconfiguration), and which only Xilinx can (... and shall, in my opinion) provide. Can you give some advice, or indicate where to search to make such points clear ?
So I am very interested in everything that uses the ICAP. I did not find the IP you mentioned, I hope it will be available soon.
03-31-2010 01:44 PM
If the configurations are made with our tools, there is no possibility of contention.
If there is contention, it is so small that it does not affect reliability.
It takes massive contention to make any substantial current.
For example, a completely random bitstream (with CRC turned OFF), may require tens of amperes, which without an adequate heatsink could exceed the Tj of the device. It is only the excessive Tj that would result in a device failure. The contention itself, would not (within the EM rules we adhere to).
01-10-2013 05:21 AM
I'm also trying to get the setCLB function working on the Virtex-5 and am encountering the same problem.
Have you managed to fix the problem of the XHI_CLB_LUT struct?
And if so would it be possible to tell me how?
01-17-2013 02:55 AM
This bug has apparently been around for years and has never been fixed by Xilinx.
I have created a replacement XHI_CLB_LUT_replacement struct to be used with the XHwIcap_SetClbBits function.
Mind that XHwIcap_mSliceXY2Slice should not be used. Instead there are 3 types of slices.
* XHI_CLB_SLICEL_ODD is used for slices with an odd x coordinate (X%2==1)
* XHI_CLB_SLICEM_EVEN is used for slices of the type SLICEM with an even x coordinate (X%2==0)
* XHI_CLB_SLICEL_EVEN is used for slices of the type SLICEL with an even x coordinate (X%2==0)
SliceM are slices that can be configured as RAM or shift registers. They always have an even x coordinate, but not every even column of slices are SliceM.
I hope this will help someone.