.. _addon_vpr_syntax: Additional Syntax to Original VPR XML ------------------------------------- .. warning:: Note this is only applicable to VPR8! Models, Complex blocks and Physical Tiles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each ```` should contain a ```` that describe the physical implementation of the ````. Note that this is fully compatible to the VPR architecture XML syntax. .. note:: ```` should include the models that describe the primitive ```` in physical mode. .. note:: Currently, OpenFPGA only supports 1 ```` to be defined under each ```` .. option:: /> OpenFPGA allows users to define it a mode is packable for VPR. By default, the packable is set to ``true``. This is mainly used for the mode that describes the physical implementation, which is typically not packable. Disable it in the packing and signficantly accelerate the packing runtime. .. note:: Once a mode is set to unpackable, its child modes will be unpackable as well. Layout ~~~~~~ ```` may include additioinal syntax to enable tileable routing resource graph generation .. option:: tileable="" Turn ``on``/``off`` tileable routing resource graph generator. Tileable routing architecture can minimize the number of unique modules in FPGA fabric to be physically implemented. Technical details can be found in :cite:`XTang_FPT_2019`. .. note:: Strongly recommend to enable the tileable routing architecture when you want to PnR large FPGA fabrics, which can effectively reduce the runtime. .. option:: through_channel="" Allow routing channels to pass through multi-width and multi-height programable blocks. This is mainly used in heterogeneous FPGAs to increase routability, as illustrated in :numref:`fig_thru_channel`. By default, it is ``off``. .. _fig_thru_channel: .. figure:: ./figures/thru_channel.png :scale: 80% :alt: Impact of through channel Impact on routing architecture when through channel in multi-width and multi-height programmable blocks: (a) disabled; (b) enabled. .. warning:: Do NOT enable ``through_channel`` if you are not using the tileable routing resource graph generator! .. warning:: You cannot use ``spread`` pin location for the ``height > 1`` or ``width >1`` tiles when using the tileable routing resource graph!!! Otherwise, it will cause undriven pins in your device!!! A quick example to show tileable routing is enabled and through channels are disabled: .. code-block:: xml Switch Block ~~~~~~~~~~~~ ```` may include addition syntax to enable different connectivity for pass tracks .. option:: sub_type="" Connecting type for pass tracks in each switch block The supported connecting patterns are ``subset``, ``universal`` and ``wilton``, being the same as VPR capability If not specified, the pass tracks will the same connecting patterns as start/end tracks, which are defined in ``type`` .. option:: sub_Fs="" Connectivity parameter for pass tracks in each switch block. Must be a multiple of 3. If not specified, the pass tracks will the same connectivity as start/end tracks, which are defined in ``fs`` A quick example which defines a switch block - Starting/ending routing tracks are connected in the ``wilton`` pattern - Each starting/ending routing track can drive 3 other starting/ending routing tracks - Passing routing tracks are connected in the ``subset`` pattern - Each passing routing track can drive 6 other starting/ending routing tracks .. code-block:: xml Routing Segments ~~~~~~~~~~~~~~~~ OpenFPGA suggests users to give explicit names for each routing segement in ```` This is used to link ``circuit_model`` to routing segments. A quick example which defines a length-4 uni-directional routing segment called ``L4`` : .. code-block:: xml .. note:: Currently, OpenFPGA only supports uni-directional routing architectures