24.04.2013 Views

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 3. GENERATING PARAMETERISED LIBRARIES WITH LAYOUT 39<br />

general use <strong>of</strong> these constructs is that each iteration <strong>of</strong> the loop need not have the same size<br />

(though it <strong>of</strong>ten will), for example the loop statements could themselves contain a conditional.<br />

Additional functions will need to be added to the placement expressions to allow placement<br />

relative to arbitrary loop constructs to be described.<br />

Block instantiations include not just instantiations <strong>of</strong> individual blocks but also series and<br />

parallel compositions <strong>of</strong> blocks. Series and parallel compositions must be given their own<br />

layout interpretation to ensure that blocks <strong>with</strong>in a composition are laid out correctly, while<br />

the whole composition itself can be placed using the at (x,y) command.<br />

An important requirement for a truly general Quartz framework is that it must be able to<br />

support the full range <strong>of</strong> Quartz block parameterisation. Two features <strong>of</strong> Quartz that differ<br />

from languages like Pebble/VHDL are a particular issue here:<br />

• Quartz blocks are relational and may have multiple possible interpretations in terms <strong>of</strong><br />

inputs/outputs. During compilation a single input/output arrangement is selected for<br />

each block however when describing the size <strong>of</strong> a block in terms <strong>of</strong> its inputs it is not<br />

always clear which parameters supplied to the block are inputs and which are outputs.<br />

• Variable parameters are not restricted to a particular “generics” region <strong>of</strong> the block<br />

interface and can be distributed anywhere throughout the block’s domain/range. Fur-<br />

thermore, Quartz blocks can output variables as well as being parameterised by input<br />

variables. The compilation <strong>of</strong> one block may therefore produce a value which impacts<br />

the compilation <strong>of</strong> a later block.<br />

Since a block size can depend on any variable parameter it is important that the block size<br />

function should be in terms <strong>of</strong> all input variables, whether in the domain or range. However,<br />

this is complicated further by polymorphism – which signals are variables and which are<br />

real hardware is not in general known. While a polymorphic variable can not effect the<br />

compilation, and hence size, <strong>of</strong> the immediate block (otherwise its type would have been<br />

deduced as either int or bool during the type-checking stage), it could be supplied as a<br />

parameter to a higher-order parameter block and (sometimes) affect that block’s size, hence<br />

affecting the calling block’s size indirectly. In order to support this possibility block size<br />

functions must be phrased in terms <strong>of</strong> all domain and range signals, since any one <strong>of</strong> them

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!