Re: [partial-reconfig] changing LUT equations

[Andres Upegui <andres.upegui@xxxxxxx>]

You can also directly modify the configuration bitstream, I do that for evolving hardware.
I'm sending you the section of the last paper that I wrote for ICES05 which describes how to modify it, (It is still in reviewing phase).

Andres

3.3 Bitstream Manipulation

Up to now, all described evolving techniques are highly dependant on Xilinx tools, making them restrictive for on-chip evolution. An attempt for providing a similar functionality from Jbits running on-chip has been proposed by Xilinx engineers [21]: XPART (Xilinx Partial Reconfiguration Toolkit) is an application program interface (API), for Microblaze or PowerPC microprocessors, that provides methods to read and modify select FPGA resources by using the ICAP (Internal Configuration Access Port). Anyway, XPART was never released.

Directly evolving the configuration bitstream has been a very common technique. It has been widely used with the XC6200 family and on other custom platforms summarized in section 1. However, in every case one must maintain a fixed section – i.e. not evolved – in the bitstream. For instance, Thompson in [10], uses an XC6216 with an array of 64x64 logic cells, but the evolved circuit uses just an array of 10x10 logic cells, while keeping fixed input and output. In this case the evolved section of the bitstream is just that containing the 10x10 array while the sections for IO blocks and the remaining cells are kept constant during the evolution.

Exactly the same principle can be applied for Virtex families, including Virtex II, Virtex II-Pro and eventually Virtex 4: LUT contents can be evolved, while keeping a fixed routing. By using hard macros, as described in 3.2, one can describe a computing cell. This computing cell can implement a neuron, a fuzzy rule, a simple LUT, or any function, including one or several LUTs; it can include also flip-flops for making the design synchronous, or it can just implement combinatorial circuits. LUTs configuration can be modified in an arbitrary way; however, routing must remain fixed. Connectivity among components of a computing cell is manually set when designing the hard macro; connectivity among computing cells is defined by an HDL description of the full system. Although routing must remain fixed during evolution, LUTs can be evolved as multiplexers, where the selection is done by the configuration bitstream. An implementation using this principle is described in [22], where they present a cellular automata evolution running on a Virtex-E.

For the Virtex family, the XAPP151 [23] describes in a detailed way the configuration bitstream, specifying the position of LUT contents on the bitstream. However, for the Virtex II family this documentation is not available and just a limited bitstream description can be found in [24]. A Virtex-II bitstream is divided by columns and each column is composed by frames. There are different column types, each type with a given number of frames, as described in figure 2 (for more details refer to [24]). However, there is no documentation about frame composition, consequently, no information about LUT contents.

Figure 2. Virtex-II configuration bitstream composition

We present in the following paragraphs how to address LUT contents on a bitstream. This problem can be solved by exploring the bitstream content. In the Virtex-II architecture each CLB has 4 slices arranged 2x2. This arrangement makes that each CLB column has 2 slices columns, which are numerated in the format XiYj, with i from 0 to 2n-1 beginning from the left (n is the number of CLB columns) and j from 0 to 2m-1 beginning from the bottom (m is the number of CLB rows). For instance, for an XC2V40 (with array 8x8) the slice placed at the top left of the component is called the slice X0Y15. Each one of these slices has 2 LUTs called G-LUT and F-LUT.

Even if it is not documented, LUT contents can be localized in the configuration bitstream. As shown in figure 2 a CLB column contains 22 frames; the contents for the first slices column LUTs – i.e. with an even X – can be found in the second frame, while for the second slices column – i.e. with an odd X – are in the third frame. Frame contents are described in Table 1. It must be noticed also that, as in Virtex family, LUT configurations are stored inverted – i.e. for an 4-input AND function, LUT contents must be 1000 0000 0000 0000, but actually it stored like 0111 1111 1111 1111 or 7F FF in hex format –. Additionally, the bit order is swapped in F-LUTs respective to G-LUTs – i.e. the same AND function in a G-LUT is stored 7F FF in the configuration bitstream, while for a F-LUT function it is stored FF FE –.

Table 1. Frame description. The first 12 bytes configure the IOB, the next 2 bytes configure the G-LUT contents for the top slice, the next byte has an unknown functionality, the next 2 configure the G-LUT, … This sequence is repeated for every slice, and finishes by the bottom IOB configuration. * Supposing it is the second frame of the first CLB column for an XC2V40.

Description	Size (bytes)
Top IOB	12
Top slice G-LUT  (slice X0Y15)*	2
--	1
Top slice F-LUT   (slice X0Y15)*	2
2nd slice G-LUT (slice X0Y14)*	2
--	1
2nd slice F-LUT (slice X0Y14)*	2
… …
Bottom slice F-LUT (slice X0Y0)*	2
Bottom IOB	12

 

Based on this description one can determine any LUT content position on the bitstream by applying the following equation:

 

Position=         Size of the header

          +   #GCLK_col_frames X  #bytes/frame

          +   #IOB_col_frames  X   #bytes/frame

          + #IOI_col_frames    X   #bytes/frame

          + #Xcoord_of_CLB_col  X  #CLB_col_frames  X  #bytes/frame

          + 1 frame X  #bytes/frame                       if slice X coord is even

          + 2 frames X  #bytes/frame                     if slice X coord is odd

          + 12 bytes                                                  -- IOB config.

          + 5 bytes X slice_Ycoord(from top)

          + 0 bytes                                                   if G-LUT

          + 3 bytes                                                    if F-LUT

 

Almost all these values are constant for every Virtex-II family devices; just the #bytes/frame depends on the number of CLB rows of the device. The header size is variable, and depends on the configuration options enabled for the bitstream (Details on the header can be found in [24]).

Accessing LUT contents on a partial bitstream is even easier, since one can directly address the target frame by setting the frame address in the bitstream header as described in [24]. Then, the table 1 description may be used for directly localizing LUT contents on the frame.

Accessing the configuration bitstream, as described in this section, allows evolving circuits in a very flexible way. By defining an initial interconnection schema one can let an on-chip – or off-chip – processor to simply modify partial bitstreams just containing the LUT-frames. This powerful approach can be largely improved when combined with the techniques proposed in sections 3.1 and 3.2, allowing additionally different connectionism schemas (unfortunately predefined and fixed). 

Grégory Mermoud wrote:

You can generate scripts for FPGA editor and run it without using the
GUI. To do that, you need to locate precisely the coordinates of the
LUT to modify. I advise you to read the following paper that deals
with such an approach:

http://ic2.epfl.ch/~gmermoud/fuzzy_hard.pdf

Grégory

On 5/27/05, Lucas Lee <lucaswb.lee@gmail.com> wrote:
  

Hi there, I have a number of LUT that I would need to modify on the fly, and
 I was wondering whether it's possible to modify the function of a LUT via a
command line without
 going through the GUI in FPGA editor? The .ncd file is binary, so there's
no straight forward way I can automate this
 with a script?
 
 Thanks.
 
 - Lucas