Revert master+wip to master (190dbbe)

Signed-off-by: Keith Rothman <[email protected]>

Author: litghost

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,9 +1,6 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: ''
-labels: ''
-assignees: ''
 
 ---
 

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,9 +1,6 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
-labels: ''
-assignees: ''
 
 ---
 

.github/ISSUE_TEMPLATE/vtr-change.md

@@ -1,14 +1,5 @@
-
-SymbiFlow WIP changes for Verilog to Routing (VTR)
-==================================================
-
-This branch contains work in progress changes for using Verilog to Routing
-(VTR) as part of SymbiFlow.
-
----
-
 # Verilog to Routing (VTR)
-[![Build Status](https://travis-ci.com/SymbiFlow/vtr-verilog-to-routing.svg?branch=master)](https://travis-ci.com/SymbiFlow/vtr-verilog-to-routing) [![Documentation Status](https://readthedocs.org/projects/vtr/badge/?version=latest)](http://docs.verilogtorouting.org/en/latest/?badge=latest)
+[![Build Status](https://travis-ci.com/verilog-to-routing/vtr-verilog-to-routing.svg?branch=master)](https://travis-ci.org/verilog-to-routing/vtr-verilog-to-routing) [![Documentation Status](https://readthedocs.org/projects/vtr/badge/?version=latest)](http://docs.verilogtorouting.org/en/latest/?badge=latest)
 
 ## Introduction
 The Verilog-to-Routing (VTR) project is a world-wide collaborative effort to provide a open-source framework for conducting FPGA architecture and CAD research and development.

README.md

@@ -80,7 +80,7 @@
   <tiles>
     <tile name="io" capacity="8">
       <equivalent_sites>
-        <site pb_type="io" pin_mapping="direct"/>
+        <site pb_type="io"/>
       </equivalent_sites>
       <input name="outpad" num_pins="1"/>
       <output name="inpad" num_pins="1"/>
@@ -95,7 +95,7 @@
     </tile>
     <tile name="clb">
       <equivalent_sites>
-        <site pb_type="clb" pin_mapping="direct"/>
+        <site pb_type="clb"/>
       </equivalent_sites>
       <input name="I" num_pins="33" equivalent="full"/>
       <output name="O" num_pins="10" equivalent="instance"/>
@@ -105,7 +105,7 @@
     </tile>
     <tile name="mult_36" height="4">
       <equivalent_sites>
-        <site pb_type="mult_36" pin_mapping="direct"/>
+        <site pb_type="mult_36"/>
       </equivalent_sites>
       <input name="a" num_pins="36"/>
       <input name="b" num_pins="36"/>
@@ -114,7 +114,7 @@
     </tile>
     <tile name="memory" height="6">
       <equivalent_sites>
-        <site pb_type="memory" pin_mapping="direct"/>
+        <site pb_type="memory"/>
       </equivalent_sites>
       <input name="addr1" num_pins="17"/>
       <input name="addr2" num_pins="17"/>

doc/src/arch/example_arch.xml

@@ -799,7 +799,7 @@ Tile
 ~~~~
 .. arch:tag:: <tile name="string" capacity="int" width="int" height="int" area="float"/>
 
-    A tile refers to a placeable element within an FPGA architecture and describes its physical compositions on the grid.
+    A tile refers to a placeable element within an FPGA architecture.
     The following attributes are applicable to each tile.
     The only required one is the name of the tile.
 
@@ -1179,46 +1179,19 @@ The following tags are common to all ``<tile>`` tags:
 
 .. arch:tag:: <equivalent_sites>
 
-    .. seealso:: For a step-by-step walkthrough on describing equivalent sites see :ref:`equivalent_sites_tutorial`.
+    Describes the Complex Blocks that can be placed within this tile.
 
-    Describes the Complex Blocks that can be placed within a tile.
-    Each physical tile can comprehend a number from 1 to N of possible Complex Blocks, or ``sites``.
-    A ``site`` corresponds to a top-level Complex Block that must be placeable in at least 1 physical tile locations.
-
-    .. arch:tag:: <site pb_type="string" pin_mapping="string"/>
+    .. arch:tag:: <site pb_type="string"/>
 
     :req_param pb_type: Name of the corresponding pb_type.
 
-    :opt_param pin_mapping: Specifies whether the pin mapping between physical tile and logical pb_type:
-
-            * ``direct``: the pin mapping does not need to be specified as the tile pin definition is equal to the corresponding pb_type one;
-            * ``custom``: the pin mapping is user-defined.
-
-
-            **Default:** ``direct``
-
-        **Example: Equivalent Sites**
-
-        .. code-block:: xml
+    **Example: Equivalent Sites**
 
-            <equivalent_sites>
-                <site pb_type="MLAB_SITE" pin_mapping="direct"/>
-            </equivalent_sites>
-
-        .. arch:tag:: <direct from="string" to="string">
-
-            Desctibes the mapping of a physical tile's port on the logical block's (pb_type) port.
-            ``direct`` is an option sub-tag of ``site``.
-
-            .. note:: This tag is need only if the pin_mapping of the ``site`` is defined as ``custom``
-
-            Attributes:
-                - ``from`` is relative to the physical tile pins
-                - ``to`` is relative to the logical block pins
-
-                .. code-block:: xml
+    .. code-block:: xml
 
-                    <direct from="MLAB_TILE.CX" to="MLAB_SITE.BX"/>
+        <equivalent_sites>
+            <site pb_type="MLAB">
+        </equivalent_sites>
 
 .. _arch_complex_blocks: