Verification of Parameterised FPGA Circuit Descriptions with Layout ...

CHAPTER 3. GENERATING PARAMETERISED LIBRARIES WITH LAYOUT 47
The standard block definition has been augmented with an set of attributes giving height
and width expressions for the block. The width of the combinator is described as the sum
of the widths of the R and S blocks, while the height is the maximum of the heights of the
R and S blocks. These manually specified size expressions are the same as those that would
have been returned by the inference algorithm SBσ β, simplified with the trivial relationship
x + 0 = x.
This laid-out beside combinator can now be used to position blocks relative to each other in
a larger circuit, with the added advantage that it can also describe the inter-connection of
the blocks. This allows the significant problem of writing correct explicit layouts to be split
into simpler and more manageable modules: in the instantiation beside(R, S) the internal
arrangement of the combinator can be ignored and only the size of the entire beside block
needs to be known.
3.5.2 Naive vs General Placement
Figure 3.8 shows a description of the Quartz map n R combinator which applies a block to each
element of a vector. The block’s function is described using a single loop which instantiates
multiple R blocks, each of which is explicitly placed at a set of co-ordinates.
The layout produced by this description for n = 4 is shown in Figure 3.9(a). At first glance
this layout appears to be correct: the grey bounding box shows the overall height of the map
block specified as a multiple of n times the height of the R block and the width is the same
as the width of R, while each block is placed with an x-offset of zero and a y-offset calculated
from the number of R blocks below it. This layout is in many cases correct, however it
relies on a key assumption: that the size of R is the same for all iterations across the vector.
The vector is polymorphic and could be a tuple containing variables which effect the size of
each R instance yet this would not be reflected in the layout generated by this naive map
implementation. Figure 3.9(b) illustrates the same map block implementation for a situation
where the R instances do not all have the same size: block placement is incorrect - leaving
empty space between blocks or causing them to overlap - and the overall size of the whole
block is also too small since two R instances lie outside the bounding box.