In order to evaluate architectural design decisions concerning heterogeneous FPGA architectures containing LEBs, the VPR architecture specification language must be extended with primitives to efficiently and flexibly describe such architectures. In this case, efficiency refers to the ability of an architect to succinctly describe the target architecture and therefore implies some degree of automation in the architecture generator that fills in the details of the architecture omitted in the interests of simpler specification. This automation is facilitated by assuming some base architectural model that exhibits a high degree of regularity and can be parameterized succinctly. However, the degree of parameterization affects the degree of flexibility provided to the architect; as such, the model chosen and its parameterization reflect a trade-off of flexibility and efficiency. Furthermore, the model chosen further affects the correlation between the automatically-generated architecture and realistic implementations. Finally, it also affects the complexity of the later stages in the tool chain — including placement and routing — and must also compromise between complexity and authenticity.

In order to ensure that our implementation could be completed and results produced in the time allotted, the revised architectural model was kept as simple as possible while still being representative of modern commercial FPGAs. To this end, all large embedded blocks (LEBs) are restricted to being arranged in columns that span the FPGA — that is, a column containing an LEB contains exclusively LEBs whereas a column containing CLBs contains exclusively CLBs (see Figure 1). Furthermore, only one type of LEBs can be included in the architecture at a given time, thereby preventing the possibility of multiple LEB types contending for the same column in the device during architecture generation.

Figure 1. Revised Island-Style FPGA Architecture with LEB Support

The architect is provided with the option of specifying either the absolute number of columns containing LEBs or the spacing of LEB columns. As the device size is chosen automatically by VPR to fit the design, neither of these specification techniques constrains the actual number of LEBs in the generated architecture as this value is determined automatically from the size of the LEBs, the number of LEB columns in the generated architecture, and the size of the array. Specifying the absolute number of LEB columns results in an architecture where the spacing between columns varies with the number of LEBs and CLBs in the design being considered; conversely, specifying the spacing of the LEB columns results in an architecture where the number of LEB columns varies with the size of the design. In either case, the architecture generation scheme endeavours to place the center the LEB columns in the array and provide roughly equal numbers of additional CLB columns at the edges of the device as necessary to meet the constraints given in the architecture specification.

To simplify the routing resource graph generation, the size of LEBs is further restricted to being one base grid unit wide, though the height of the LEB can be varied arbitrarily. Restricting LEB width to a single column allows one to assume that horizontal routing can cross the middle of the LEB (somewhat justifiably, supposing enough metal layers are available). Furthermore, the single-column restriction prevents the LEB from ever interfering with switchbox placement. Consequently, this restriction dramatically simplifies the routing graph generation. Although the n x 1 size restriction on LEBs does not correspond with the reality of modern FPGAs, the columnar localization is consistent with both the Xilinx Virtex-II [Xilinx2005] and Altera Stratix II [Altera2005] architectures, among others.

It should also be noted that the restriction of CLBs to be a single column wide only affects the routing portion of our extensions to VPR. All other phases of VPR from architecture description to placement can accommodate columns of LEBs with dimensions of n x m base grid units. Furthermore, the restriction to only one type of LEB per architecture description is a limitation imposed at the architecture generation stage — that is, the architecture specification and specification parsing components support an arbitrary number of LEBs.

Under this architectural model, the architect is responsible for specifying not only on which side of the LEB each pin lies, but also the precise position along that side the pin occupies. This is accomplished by specifying the offset in base grid units of the pin along the side of the LEB (see Figure 2). The offset specifies which channel segment adjacent to the LEB a pin connects to and is measured from the bottom or left side of the LEB, depending on the side on which the pin lies — pins of the left and right sides of the LEB are offset from the bottom of the LEB and pins on the top and bottom sides of the LEB are offset from the left side of the LEB.

Figure 2. Specifying Pin Placement on LEBs

Lastly, the architect is also responsible for specifying the connection block flexibilities of the LEBs as a distinct parameter from the connection block flexibilities of the CLBs. As with I/O blocks and CLBs, the input and output connection block flexibilities can be specified as either fractional or absolute values.

To specify the size and frequency of blocks in the architecture, a blocktype directive has been added. This directive should be used to define all block types in the architecture, including CLBs; however, the current architecture specification parser includes a backwards-compatibility mode whereby it can identify implicitly-defined CLBs. The format of the blocktype directive is:

blocktype <identifier> (spacing <int>)|(absolute <int>)|fill height <int> width <int>

• The <identifier> specifies the name used to reference this block throughout the remainder of the architecture specification file.
• The number of columns containing blocks of this type (i.e. the block frequency type) can be specified in one of three ways:
  • spacing <int>: Fill every <int>th column in the array with blocks of this type. For wide blocks (which are not supported for routing), each wide block column is counted as a single column even though it spans multiple grid columns. This ultimately creates LEB columns in the array.
  • absolute <int>: Fill exactly <int> columns of the array with blocks of this type. The actual spacing of the columns is determined once the size of the array is known.
  • fill: Fill all remaining columns with blocks of this type. There can be only one fill block frequency type per architecture. The implicit CLB type is created as having a fill block frequency type.
• The width and height parameters specify the block's width and height in base grid units. The implicit CLB block type is created with a size of 1 x 1.

The inpin and outpin directives have been extended to support specifying the pin locations on multiple blocks and to support placing pins at non-zero offsets along blocks. The new format of the directive is:

[<identifier>] inpin|outpin class: <int> <side> [offset: <int>] [<side> [offset: <int>]] [...]

• The <identifier> refers to a previously-defined block type. It may be omitted, in which case the pin definition is associated with the implicit CLB block type.
• The inpin, outpin, class: <int>, and <side> parameters all retain their meaning from the original VPR architecture specification format.
• The offset: <int> parameter has been added to specify the offset of the pin along the side specified either from the left side of the LEB (for pins on the top and bottom sides) or from the bottom of the LEB (for pins on the left and right sides). If omitted, the offset: <int> parameter is assumed to be zero.

Likewise, the Fc_input and Fc_output directives have been extended to support associating them with specific block types. The new format for these directives is:

[<identifier>] Fc_input|Fc_output <float>

• As above, the <identifier> refers to a previously-defined block type. It may be omitted, in which case the input/output flexibility definition is associated with the implicit CLB block type.
• As in the original architecture file format, the <float> parameter specifies either the absolute or the fractional connection block input or output flexibility. It bears noting that the Fc_type directive is still applied globally and as such all Fc_input and Fc_output values for all block types must be specified in the same format, either absolute or fractional.

For examples of the sorts of architectures that can be generated using this specification format, please refer to Architecture Generation Pictures and Placement Pictures.

Last updated Dec 2005