Merge pull request #1741 from lnis-uofu/xt_clkntwk2

Support Connection Blocks on Perimeter Tiles

docs/source/manual/arch_lang/addon_vpr_syntax.rst

@@ -88,6 +88,23 @@ Layout
 
   .. warning:: Do NOT enable ``shrink_boundary`` if you are not using the tileable routing resource graph generator!
 
+.. option:: perimeter_cb="<bool>"
+
+  Allow connection blocks to appear around the perimeter programmable block (mainly I/Os). This is designed to enhance routability of I/Os on perimeter. Also strongly recommended when programmable clock network is required to touch clock pins on I/Os. As illustrated in :numref:`fig_perimeter_cb`, routing tracks can access three sides of each I/O when perimeter connection blocks are created. 
+  By default, it is ``false``.
+
+.. warning:: When enabled, please only place outputs at one side of I/Os. For example, outputs of an I/O on the top side can only occur on the bottom side of the I/O tile. Otherwise, routability loss may be expected, leading to some pins cannot be reachable. Enable the ``opin2all_sides`` to recover routability loss. 
+
+  .. _fig_perimeter_cb:
+
+  .. figure:: ./figures/perimeter_cb.png
+     :width: 100%
+     :alt: Impact of perimeter_cb
+
+     Impact on routing architecture when perimeter connection blocks are : (a) disabled; (b) enabled.
+
+  .. warning:: Do NOT enable ``perimeter_cb`` if you are not using the tileable routing resource graph generator!
+
 .. option:: opin2all_sides="<bool>"
 
   Allow each output pin of a programmable block to drive the routing tracks on all the sides of its adjacent switch block (see an illustrative example in :numref:`fig_opin2all_sides`). This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block. 

docs/source/manual/file_formats/clock_network.rst

@@ -14,6 +14,8 @@ Using the clock network description language, users can define multiple clock ne
 - A number of switch points which interconnects clock spines using programmable routing switches. See details in :ref:`file_formats_clock_network_switch_point`.
 - A number of tap points which connect the clock spines to programmable blocks, e.g., CLBs. See details in :ref:`file_formats_clock_network_tap_point`.
 
+The entry point of a clock tree must be at a valid connection block.
+
 .. note:: Please note that the levels of a clock network will be automatically inferred from the clock spines and switch points. Clock network will be **only** built based on the width and the number of levels, as well as the tap points.
 
 .. note:: The switch points and clock spines will be used to route a clock network. The switch points will not impact the physical clock network but only impact the configuration of the programmable routing switches in the physical clock network.
@@ -45,6 +47,17 @@ Using the clock network description language, users can define multiple clock ne
 
    An example of programmable clock network considering a 2x2 FPGA fabric
 
+Note that when the ``perimeter_cb`` is enabled for routing architecture (See details in :ref:`addon_vpr_syntax`), clock entry point can be indeed at the fringe of FPGA fabrics. See example in :numref:`prog_clock_network_example_2x2_perimeter_cb`. 
+
+.. _fig_prog_clock_network_example_2x2_perimeter_cb:
+
+.. figure:: figures/prog_clk_network_example_2x2_perimeter_cb.png
+   :width: 100%
+   :alt: An example of programmable clock network considering a 2x2 FPGA fabric with perimeter cb
+
+   An example of programmable clock network considering a 2x2 FPGA fabric with perimeter cb
+
+
 General Settings
 ^^^^^^^^^^^^^^^^
 
@@ -134,6 +147,8 @@ Clock Spine Settings
 The following syntax are applicable to the XML definition tagged by ``spine``.
 Note that a number of clock spines can be defined under the node ``clock_network``.
 
+.. note:: Use coordinates of connection blocks to define the starting and ending points of clock spines.
+
 .. option:: name="<string>"
 
   The unique name of the clock spine. It will be used to build switch points between other clock spines.
@@ -172,6 +187,8 @@ Switch Point Settings
 The following syntax are applicable to the XML definition tagged by ``switch_point``.
 Note that a number of switch points can be defined under each clock spine ``spine``.
 
+.. note:: Use the coordinate of switch block to define switching points!
+
 .. option:: tap="<string>"
 
   Define which clock spine will be tapped from the current clock spine.
@@ -292,6 +309,8 @@ For example,
 
 where all the clock spines of the clock network ``clk_tree_0`` tap the clock pins ``clk`` of tile ``clb`` in a VPR architecture description file:
 
+.. note:: Use the name of ``subtile`` in the ``to_pin`` when there are a number of subtiles in your tile!
+
 .. code-block:: xml
 
   <tile name="clb">

docs/source/manual/file_formats/tile_config_file.rst

@@ -24,7 +24,7 @@ Detailed syntax are presented as follows.
 
   Specify the style of tile organization. Can be [``top_left`` | ``top_right`` | ``bottom_left`` | ``bottom_right`` | ``custom``]
 
-  .. warning:: Currently, only ``top_left`` is supported!
+  .. warning:: Currently, only ``top_left`` and ``bottom_left`` are supported!
 
   The ``top_left`` is a shortcut to define the organization for all the tiles. :numref:`fig_tile_style_top_left` shows an example of tiles in the top-left sytle, where the programmable block locates in the top-left corner of all the tiles, surrounded by two connection blocks and one switch blocks.
 
@@ -37,3 +37,14 @@ Detailed syntax are presented as follows.
    An example of top-left style of a tile in FPGA fabric
 
 
+  The ``bottom_left`` is a shortcut to define the organization for all the tiles. :numref:`fig_tile_style_bottom_left` shows an example of tiles in the bottom-left sytle, where the programmable block locates in the bottom-left corner of all the tiles, surrounded by two connection blocks and one switch blocks.
+
+.. _fig_tile_style_bottom_left:
+
+.. figure:: ./figures/tile_style_bottom_left.png
+   :width: 100%
+   :alt: An example of bottom-left style of tile
+
+   An example of bottom-left style of a tile in FPGA fabric
+
+

docs/source/manual/openfpga_shell/openfpga_commands/fpga_verilog_commands.rst

@@ -14,6 +14,14 @@ write_fabric_verilog
 
     Specify the output directory for the Verilog netlists. For example, ``--file /temp/fabric_netlist/``
 
+  .. option:: --constant_undriven_inputs
+
+  .. note:: This option is automatically enabled when the option ``perimeter_cb`` of tileable routing resource graph is enabled (see details in :ref`addon_vpr_syntax`). 
+
+  .. note:: Enable this option may shadow issues in your FPGA architecture, which causes them difficult to be found in design verification.
+
+    Use constant gnd for undriven wires in Verilog netlists. Recommand to enable when there are boundary routing tracks in FPGA fabric.
+
   .. option:: --default_net_type <string>
 
     Specify the default net type for the Verilog netlists. Currently, supported types are ``none`` and ``wire``. Default value: ``none``.

openfpga/src/annotation/annotate_rr_graph.cpp

@@ -98,7 +98,7 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
                           const vtr::Point<size_t>& gsb_range,
                           const size_t& layer,
                           const vtr::Point<size_t>& gsb_coord,
-                          const bool& include_clock) {
+                          const bool& perimeter_cb, const bool& include_clock) {
   /* Create an object to return */
   RRGSB rr_gsb;
 
@@ -126,7 +126,6 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
 
     switch (side) {
       case TOP: /* TOP = 0 */
-        /* For the border, we should take special care */
         if (gsb_coord.y() == gsb_range.y()) {
           rr_gsb.clear_one_side(side_manager.get_side());
           break;
@@ -157,7 +156,6 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
 
         break;
       case RIGHT: /* RIGHT = 1 */
-        /* For the border, we should take special care */
         if (gsb_coord.x() == gsb_range.x()) {
           rr_gsb.clear_one_side(side_manager.get_side());
           break;
@@ -189,8 +187,7 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
           gsb_coord.x() + 1, gsb_coord.y(), OPIN, opin_grid_side[1]);
         break;
       case BOTTOM: /* BOTTOM = 2*/
-        /* For the border, we should take special care */
-        if (gsb_coord.y() == 0) {
+        if (!perimeter_cb && gsb_coord.y() == 0) {
           rr_gsb.clear_one_side(side_manager.get_side());
           break;
         }
@@ -220,8 +217,7 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
           gsb_coord.y(), OPIN, opin_grid_side[1]);
         break;
       case LEFT: /* LEFT = 3 */
-        /* For the border, we should take special care */
-        if (gsb_coord.x() == 0) {
+        if (!perimeter_cb && gsb_coord.x() == 0) {
           rr_gsb.clear_one_side(side_manager.get_side());
           break;
         }
@@ -333,11 +329,11 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
       case RIGHT: /* RIGHT = 1 */
         /* For the bording, we should take special care */
         /* Check if TOP side chan width is 0 or not */
-        chan_side = TOP;
+        chan_side = BOTTOM;
         /* Build the connection block: ipin and ipin_grid_side */
-        /* LEFT side INPUT Pins of Grid[x+1][y+1] */
+        /* LEFT side INPUT Pins of Grid[x+1][y] */
         ix = rr_gsb.get_sb_x() + 1;
-        iy = rr_gsb.get_sb_y() + 1;
+        iy = rr_gsb.get_sb_y();
         ipin_rr_node_grid_side = LEFT;
         break;
       case BOTTOM: /* BOTTOM = 2*/
@@ -353,11 +349,11 @@ static RRGSB build_rr_gsb(const DeviceContext& vpr_device_ctx,
       case LEFT: /* LEFT = 3 */
         /* For the bording, we should take special care */
         /* Check if left side chan width is 0 or not */
-        chan_side = TOP;
+        chan_side = BOTTOM;
         /* Build the connection block: ipin and ipin_grid_side */
-        /* RIGHT side INPUT Pins of Grid[x][y+1] */
+        /* RIGHT side INPUT Pins of Grid[x][y] */
         ix = rr_gsb.get_sb_x();
-        iy = rr_gsb.get_sb_y() + 1;
+        iy = rr_gsb.get_sb_y();
         ipin_rr_node_grid_side = RIGHT;
         break;
       default:
@@ -420,6 +416,9 @@ void annotate_device_rr_gsb(const DeviceContext& vpr_device_ctx,
    */
   vtr::Point<size_t> gsb_range(vpr_device_ctx.grid.width() - 1,
                                vpr_device_ctx.grid.height() - 1);
+  if (vpr_device_ctx.arch->perimeter_cb) {
+    gsb_range.set(vpr_device_ctx.grid.width(), vpr_device_ctx.grid.height());
+  }
   device_rr_gsb.reserve(gsb_range);
 
   VTR_LOGV(verbose_output, "Start annotation GSB up to [%lu][%lu]\n",
@@ -434,11 +433,11 @@ void annotate_device_rr_gsb(const DeviceContext& vpr_device_ctx,
        * the GSBs at the borderside correctly sort drive_rr_nodes should be
        * called if required by users
        */
-      const RRGSB& rr_gsb =
-        build_rr_gsb(vpr_device_ctx,
-                     vtr::Point<size_t>(vpr_device_ctx.grid.width() - 2,
-                                        vpr_device_ctx.grid.height() - 2),
-                     layer, vtr::Point<size_t>(ix, iy), include_clock);
+      vtr::Point<size_t> sub_gsb_range(vpr_device_ctx.grid.width() - 1,
+                                       vpr_device_ctx.grid.height() - 1);
+      const RRGSB& rr_gsb = build_rr_gsb(
+        vpr_device_ctx, sub_gsb_range, layer, vtr::Point<size_t>(ix, iy),
+        vpr_device_ctx.arch->perimeter_cb, include_clock);
       /* Add to device_rr_gsb */
       vtr::Point<size_t> gsb_coordinate = rr_gsb.get_sb_coordinate();
       device_rr_gsb.add_rr_gsb(gsb_coordinate, rr_gsb);