update documentation in simulation setting syntax

docs/source/arch_lang/addon_vpr_syntax.rst

@@ -0,0 +1,37 @@
+.. _addon_vpr_syntax:
+
+Additional Syntax to Original VPR XML
+-------------------------------------
+
+.. warning:: Note this is only applicable to VPR8!
+
+  
+Each ``<pb_type>`` should contain a ``<mode>`` that describe the physical implementation of the ``<pb_type>``. Note that this is fully compatible to the VPR architecture XML syntax.
+  
+``<model>`` should include the models that describe the primitive ``<pb_type>`` in physical mode.
+  
+``<layout>`` may include additioinal syntax to enable tileable routing resource graph generation
+
+.. option:: tileable="<bool>"
+
+  Turn on/off tileable routing resource graph generator
+
+``<switch_block>`` may include addition syntax to enable different connectivity for pass tracks
+
+.. option:: sub_type="<string>"
+  
+  Connecting type for pass tracks in each switch block
+  If not specified, the pass tracks will the same connecting patterns as start/end tracks, which are defined in ``type``
+
+.. option:: sub_Fs="<int>"
+
+  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``
+
+.. note:: Currently, OpenFPGA only supports uni-directional routing architectures
+
+.. note:: Currently, OpenFPGA only supports 1 ``<equivalent_sites>`` to be defined under each ``<tile>``
+
+.. note:: OpenFPGA require explicit names to be defined for each routing segement in ``<segmentlist>`` 
+
+

docs/source/arch_lang/annotate_vpr_arch.rst

@@ -1,9 +1,11 @@
-Link circuit modules
---------------------
+.. _annotate_vpr_arch:
+
+Bind circuit modules to VPR architecture 
+----------------------------------------
 Each defined circuit model should be linked to an FPGA module defined in the original part of architecture descriptions. It helps FPGA-circuit creating the circuit netlists for logic/routing blocks. Since the original part lacks such support, we create a few XML properties to link to Circuit models.
 
 SRAM
-====
+~~~~
 
 To link the defined circuit model of SRAM into the FPGA architecture description, a new line in XML format should be added under the XML node device. The new XML node is named as sram, which defines the area of an SRAM and the name of the circuit model to be linked. An example is shown as follows:
 
@@ -42,7 +44,7 @@ Here is an example.
 
 
 Switch Boxes
-=============
+~~~~~~~~~~~~
 
 Original VPR architecture description contains an XML node called switchlist under which all the multiplexers of switch blocks are described.
 To link a defined circuit model to a multiplexer in the switch blocks, a new XML property circuit_model_name should be added to the descriptions.
@@ -59,7 +61,7 @@ Here is an example:
 
 
 Connection Blocks
-==================
+~~~~~~~~~~~~~~~~~
 
 To link the defined circuit model of the multiplexer to the Connection Blocks, a circuit_model_name should be added to the definition of Connection Blocks switches.  However, the original architecture descriptions do not offer a switch description for connection boxes as they do for the switch blocks.
 Therefore, FPGA-circuit requires a new XML node called **cblock** under the root XML node architecture, where a switch for connection blocks can be defined.
@@ -75,7 +77,7 @@ Here is the example:
 * **circuit_model_name:** should match a circuit model whose type is mux defined under module_circuit_models.
 
 Channel Wire Segments
-=====================
+~~~~~~~~~~~~~~~~~~~~~
 
 Similar to the Switch Boxes and Connection Blocks, the channel wire segments in the original architecture descriptions can be adapted to provide a link to the defined circuit model.
 
@@ -88,7 +90,7 @@ Similar to the Switch Boxes and Connection Blocks, the channel wire segments in
 * circuit_model_name: should match a circuit model whose type is chan_wire defined under module_circuit_models.
 
 Primitive Blocks inside Multi-mode Configurable Logic Blocks
-=============================================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The architecture description employs a hierarchy of ``pb_types`` to depict the sub-modules and complex interconnections inside logic blocks. Each leaf node and interconnection in the pb_type hierarchy should be linked to a circuit model.
 Each primitive block, i.e., the leaf ``pb_types``, should be linked to a valid circuit model, using the XML syntax ``circuit_model_name``.

docs/source/arch_lang/circuit_library.rst

@@ -1,13 +1,15 @@
-Define Circuit-level Modules
-============================
+.. _circuit_library:
+
+Circuit Library
+---------------
 
 To support FPGA Verilog/SPICE, Verily and Bitstream Generator, physical modules containing gate-level and transistor-level features are required for FPGA primitive blocks.
 The physical modules are defined in XML syntax, similar to the original VPR FPGA architecture description language.
 
 For each module that appears in the FPGA architecture, a circuit model should be defined. In the definition of a circuit model, the user can specify if the Verilog/SPICE netlist of the module is either auto-generated or user-defined.
 
-Define circuit_models
----------------------
+Circuit Model Attributes
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -43,8 +45,8 @@ Define circuit_models
 .. note:: Under the XML node circuit_model, the features of transistor-level designs can be defined. In the following table, we show the common features supported for all the modules.  Then, we will introduce unique features supported only for some circuit models types.
 
 
-Transistor level
-----------------
+Design Technology-related Attributes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -65,6 +67,14 @@ Transistor level
 
 .. note:: Currently, the RRAM-based designs are only supported for multiplexers.
 
+
+Input/Output Buffer
+~~~~~~~~~~~~~~~~~~~
+
+Circuit Port Attributes
+~~~~~~~~~~~~~~~~~~~~~~~
+
+
 * input_buffer and output_buffer:
     
     * **exist:** [on|off]. Define the existence of the input_buffer or output_buffer. Note that the existence is valid for all the inputs and outputs. Note that if users want only part of the inputs (or outputs) to be buffered, this is not supported here. A solution can be building a user-defined Verilog/SPICE netlist.

docs/source/arch_lang/circuit_model_examples.rst

@@ -1,9 +1,11 @@
+.. _circuit_model_examples:
+
 Circuit model examples
-======================
+----------------------
 The next subsections are dedicated to detailed examples of each circuit model type. Through these examples, we give a global overview of the different implementations which are available for the user.
 
 Inverters and Buffers
----------------------
+~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -131,7 +133,7 @@ This example shows:
 
 
 Pass-gate Logic
----------------
+~~~~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -212,7 +214,7 @@ This example shows:
 
 
 SRAMs
------
+~~~~~
 
 .. code-block:: xml
 
@@ -231,7 +233,7 @@ SRAMs
 .. note:: The support SRAM modules should have a BL and a WL when the memory-bank-style configuration circuit is declared. Note that the WL should be the write/read enable signal, while BL is the data input.
 
 Logic gates
------------
+~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -250,7 +252,7 @@ Logic gates
 .. note:: It may happen that the port sequence in generated Verilog netlists has conflicts with the port sequence in standard and customized cells. To avoid this, users can set the XML keyword ``dump_explicit_port_map`` to be true, which enables explicit port mapping are dumped. Users can specify the pin/port name in the standard cell library using the XML keyword ``lib_name``.
 
 Multiplexers
-------------
+~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -353,7 +355,7 @@ If we arbitrarily fix the number of Mux entries at 4, the following code could i
 	* The number of entries parametrized by ``size`` in input port-type.
 
 Look-Up Tables
---------------
+~~~~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -425,7 +427,7 @@ The code describing this LUT is:
 	* How each blocks is defined
 
 Flip-Flops
-----------
+~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -509,7 +511,7 @@ The code describing this FF is:
 	* 1 port, ``clk``, defined as global
 
 Hard Logics
------------
+~~~~~~~~~~~
 
 .. code-block:: xml
 
@@ -533,7 +535,7 @@ Instructions of defining design parameters:
 * **port:** two types of ports (``input`` and ``output``) should be defined. If the user provides a user-defined Verilog/SPICE netlist, the bandwidth of ports should be defined to the same as the Verilog/SPICE netlist.
 
 Routing Wire Segments
----------------------
+~~~~~~~~~~~~~~~~~~~~~
 
 FPGA-Verilog/SPICE provides two types of Verilog/SPICE models for the wire segments in FPGA architecture:
 
@@ -596,7 +598,7 @@ The code describing this wire is:
 	* How to use this circuit_model to auto-generate the Verilog/SPICE netlist
 
 I/O pads
---------
+~~~~~~~~
 
 .. code-block:: xml
 

docs/source/arch_lang/direct_interconnect.rst

@@ -1,10 +1,12 @@
-Interconnection extensions
-==========================
+.. _direct_interconnect:
+
+Inter-Tile Direct Interconnection extensions
+--------------------------------------------
 
 This section introduces extensions on the architecture description file about existing interconnection description.
 
 Directlist
-----------
+~~~~~~~~~~
 
 The original direct connections in the directlist section are documented here_. Its description is given below:
 
@@ -26,40 +28,49 @@ Our extension include three more options:
     <direct name="string" from_pin="string" to_pin="string" x_offset="int" y_offset="int" z_offset="int" switch_name="string" interconnection_type="string" x_dir="string" y_dir="string"/>
   </directlist>
 
-.. note:: these options are optional. However, if *interconnection_type* is set *x_dir* and *y_dir* are required.
+.. note:: these options are optional. However, if `interconnection_type` is set `x_dir` and `y_dir` are required.
 
-* **interconnection_type**: [``NONE`` | ``column`` | ``row``], specifies if it applies on a column or a row ot if it doesn't apply.
+.. option:: interconnection_type="<string>"
 
-* **x_dir**: [``positive`` | ``negative``], specifies if the next cell to connect has a bigger or lower x value. Considering a coordinate system where (0,0) is the origin at the bottom left and *x* and *y* are positives: 
+  the type of interconnection should be a string.
+  Available types are ``NONE`` | ``column`` | ``row``, specifies if it applies on a column or a row ot if it doesn't apply.
 
-    * x_dir="positive": 
+.. option:: x_dir="<string>"
 
-        * interconnection_type="column": a column will be connected to a column on the **right**, if it exists.
+  Available directionalities are ``positive`` | ``negative``, specifies if the next cell to connect has a bigger or lower ``x`` value.
+  Considering a coordinate system where (0,0) is the origin at the bottom left and ``x`` and ``y`` are positives: 
 
-        * interconnection_type="row": the most on the **right** cell from a row connection will connect the most on the **left** cell of next row, if it exists.
+    - x_dir="positive": 
 
-    * x_dir="negative": 
+        - interconnection_type="column": a column will be connected to a column on the ``right``, if it exists.
 
-        * interconnection_type="column": a column will be connected to a column on the **left**, if it exists.
+        - interconnection_type="row": the most on the ``right`` cell from a row connection will connect the most on the ``left`` cell of next row, if it exists.
 
-        * interconnection_type="row": the most on the **left** cell from a row connection will connect the most on the **right** cell of next row, if it exists.
+    - x_dir="negative": 
 
-* **y_dir**: [``positive`` | ``negative``], specifies if the next cell to connect has a bigger or lower x value. Considering a coordinate system where (0,0) is the origin at the bottom left and *x* and *y* are positives:
+        - interconnection_type="column": a column will be connected to a column on the ``left``, if it exists.
 
-    * y_dir="positive": 
+        - interconnection_type="row": the most on the ``left`` cell from a row connection will connect the most on the ``right`` cell of next row, if it exists.
 
-        * interconnection_type="column": the **bottom** cell of a column will be connected to the next column **top** cell, if it exists.
+.. option:: y_dir="<string>"
 
-        * interconnection_type="row": a row will be connected on an **above** row, if it exists.
+  Available directionalities are ``positive`` | ``negative``, specifies if the next cell to connect has a bigger or lower x value.
+  Considering a coordinate system where (0,0) is the origin at the bottom left and `x` and `y` are positives:
 
-    * y_dir="negative": 
+    - y_dir="positive": 
 
-        * interconnection_type="column": the **top** cell of a column will be connected to the next column **bottom** cell, if it exists.
+        - interconnection_type="column": the ``bottom`` cell of a column will be connected to the next column ``top`` cell, if it exists.
 
-        * interconnection_type="row": a row will be connected on a row **below**, if it exists.
+        - interconnection_type="row": a row will be connected on an ``above`` row, if it exists.
+
+    - y_dir="negative": 
+
+        - interconnection_type="column": the ``top`` cell of a column will be connected to the next column ``bottom`` cell, if it exists.
+
+        - interconnection_type="row": a row will be connected on a row ``below``, if it exists.
 
 Example
--------
+~~~~~~~
 
 For this example, we will study a scan-chain implementation. The description could be:
 
@@ -81,7 +92,7 @@ For this example, we will study a scan-chain implementation. The description cou
 In this figure, the red arrows represent the initial direct connection. The green arrows represent the point to point connection to connect all the columns of CLB.
 
 Truth table
------------
+~~~~~~~~~~~
 
 A point to point connection can be applied in different ways than showed in the example section. To help the designer implement his point to point connection, a truth table with our new parameters id provided below.
 

docs/source/arch_lang/generality.rst

@@ -1,8 +1,46 @@
+.. _generality:
+
 General Hierarchy
-=================
+-----------------
+
+For OpenFPGA using VPR7
+~~~~~~~~~~~~~~~~~~~~~~~
+
 The extension of the VPR architectural description language is developed as an independent branch of the original one. Most of the FPGA-SPICE descriptions are located under a XML node called <spice_settings>, which is a child node under the root node <architecture>. 
 Under the <spice_settings>, some child node is created for describing SPICE simulation settings, technology library and transistor-level modeling of circuit modules.
 In the following sub-sections, we will introduce the structures of these XML nodes and the parameters provided.
 
+For OpenFPGA using VPR8
+~~~~~~~~~~~~~~~~~~~~~~~
+
+OpenFPGA uses a separated XML file other than the VPR8 architecture description file.
+This is to keep a loose integration to VPR8 so that OpenFPGA can easily integrate any future version of VPR with least engineering effort.
+However, to implement a physical FPGA, OpenFPGA requires the original VPR XML to include full physical design details.
+Full syntax can be found in :ref:`addon_vpr_syntax`.
+
+The OpenFPGA architecture description XML file consisting of the following parts:
+
+  - ``<openfpga_architecture>`` contains architecture-level information, such as device-level description, circuit-level and architecture annotations to original VPR architecture XML. It consists of the following code blocks
+
+    - ``<circuit_library>`` includes a number of ``circuit_model``, each of which describe a primitive block in FPGA architecture, such as Look-Up Tables and multiplexers. Full syntax can be found in :ref:`circuit_library`.
+    - ``<technology_library>`` includes transistor-level parameters, where users can specify which transistor models are going to be used when building the ``circuit models``. 
+    - ``<configuration_protocol>`` includes detailed description on the configuration protocols to be used in FPGA fabric.
+    - ``<connection_block>`` includes annotation on the connection block definition ``<connection_block>`` in original VPR XML
+    - ``<switch_block>`` includes annotation on the switch block definition ``<switchlist>`` in original VPR XML
+    - ``<routing_segment>`` includes annotation on the routing segment definition ``<segmentlist>`` in original VPR XML
+    - ``<direct_connection>`` includes annotation on the inter-tile direct connection definitioin ``<directlist>`` in original VPR XML
+    - ``<pb_type_annotation>`` includes annotation on the programmable block architecture ``<complexblocklist>`` in original VPR XML
+
+  - ``<openfpga_simulation_setting>`` includes all the parameters to be used in generate testbenches in simulation purpose. Full syntax can be found in :ref:`simulation_setting`.
+
+    - ``<clock_setting>`` defines the clock-related settings in simulation, such as clock frequency and number of clock cycles to be used
+    - ``<simulator_option>`` defines universal options available in both HDL and SPICE simulators. This is mainly used by FPGA-SPICE
+    - ``<monte_carlo>`` defines critical parameters to be used in monte-carlo simulations. This is used by FPGA-SPICE
+    - ``<measurement_setting>`` defines the parameters used to measure signal slew and delays. This is used by FPGA-SPICE
+    - ``<stimulus>`` defines the parameters used to generate voltage stimuli in testbenches. This is used by FPGA-SPICE
+
+.. note:: ``<technology_library>`` will be applied to ``circuit_model`` when running FPGA-SPICE. It will not impact FPGA-Verilog, FPGA-Bitstream, FPGA-SDC.
+
+.. note:: the parameters in ``<clock_setting>`` will be applied to both FPGA-Verilog and FPGA-SPICE simulations
 
 

docs/source/arch_lang/index.rst

@@ -1,6 +1,3 @@
-Extended Architecture Description Language
-==========================================
-
 .. _arch_lang:
    Extended FPGA Architecture Description Language
  
@@ -9,16 +6,18 @@ Extended Architecture Description Language
 
    generality
 
-   interconnect
-   
-   spice_sim_setting
+   addon_vpr_syntax
 
-   tech_lib
+   direct_interconnect 
+   
+   simulation_setting
+
+   technology_library
   
-   circuit_modules
+   circuit_library
   
    circuit_model_examples
   
-   link_circuit_modules
+   annotate_vpr_arch
 
    

docs/source/arch_lang/simulation_setting.rst

@@ -1,5 +1,11 @@
-Parameters for SPICE simulation settings
-========================================
+.. _simulation_setting:
+
+Simulation settings
+-------------------
+
+For OpenFPGA using VPR7
+~~~~~~~~~~~~~~~~~~~~~~~
+
 All the parameters that need to be defined in the HSPICE simulations are located under a child node called <parameters>, which is under its father node <spice_settings>. 
 The parameters are divided into three categories and can be defined in three XML nodes, <options>, <measure> and <stimulate>, respectively. 
 
@@ -130,5 +136,149 @@ Define the starting and ending point in measuring the delay between two signals
 * **input_thres_pct:** the starting point in measuring the delay of a falling edge. It is expressed as a percentage of the maximum voltage of a signal. For example, upper_thres_pct=0.5 is depicted in :numref:`fig_meas_edge`. 
     
 * **output_thres_pct:** the ending point in measuring the delay of a falling edge. It is expressed as a percentage of the maximum voltage of a signal. For example, lower_thres_pct=0. 5 is depicted in :numref:`fig_meas_edge`.
+
+
+For OpenFPGA using VPR8
+~~~~~~~~~~~~~~~~~~~~~~~
+
+All the simulation settings are stored under the XML node ``<openfpga_simulation_setting>``
+General organization is as follows
+
+.. code-block:: xml
+
+    <openfpga_simulation_setting>
+      <clock_setting>
+        <operating frequency="<int>|<string>" num_cycles="<int>|<string>" slack="<float>"/>
+        <programming frequency="<int>"/>
+      </clock_setting>
+      <simulator_option>
+        <operating_condition temperature="<int>"/>
+        <output_log verbose="<bool>" captab="<bool>"/>
+        <accuracy type="<string>" value="<float>"/>
+        <runtime fast_simulation="<bool>"/>
+      </simulator_option>
+      <monte_carlo num_simulation_points="<int>"/>
+      <measurement_setting>
+        <slew>
+          <rise upper_thres_pct="<float>" lower_thres_pct="<float>"/>
+          <fall upper_thres_pct="<float>" lower_thres_pct="<float>"/>
+        </slew>
+        <delay>
+          <rise input_thres_pct="<float>" output_thres_pct="<float>"/>
+          <fall input_thres_pct="<float>" output_thres_pct="<float>"/>
+        </delay>
+      </measurement_setting>
+      <stimulus>
+        <clock>
+          <rise slew_type="<string>" slew_time="<float>"/>
+          <fall slew_type="<string>" slew_time="<float>"/>
+        </clock>
+        <input>
+          <rise slew_type="<string>" slew_time="<float>"/>
+          <fall slew_type="<string>" slew_time="<float>"/>
+        </input>
+      </stimulus>
+    </openfpga_simulation_setting>
+
+Clock Setting
+^^^^^^^^^^^^^
+Clock setting focuses on defining the clock periods to applied on FPGA fabrics
+As a programmable device, an FPGA has two types of clocks. 
+The first is the operating clock, which is applied by users' implementations.
+The second is the programming clock, which is applied on the configuration protocol to load users' implementation to FPGA fabric.
+OpenFPGA allows users to freely define these clocks as well as the number of clock cycles.
+We should the full syntax in the code block below and then provide details on each of them.
+
+.. code-block:: xml
+
+  <clock_setting>
+    <operating frequency="<float>|<string>" num_cycles="<int>|<string>" slack="<float>"/>
+    <programming frequency="<float>"/>
+  </clock_setting>
+
+Operating clock setting
+```````````````````````
+Operating clocks are defined under the XML node ``<operating>``
+
+- ``frequency="<float|string>``
+  Specify frequency of the operating clock. OpenFPGA allows users to specify an absolute value in the unit of ``[Hz]`` 
+  Alternatively, users can bind the frequency to the maximum clock frequency analyzed by VPR STA engine.
+  This is very useful to validate the maximum operating frequency for users' implementations
+  In such case, the value of this attribute should be a reserved word ``auto``.
+
+- ``num_cycles="<int>|<string>"``
+  can be either ``auto`` or an integer. When set to ``auto``, OpenFPGA will infer the number of clock cycles from the average/median of all the signal activities.
+  When set to an integer, OpenFPGA will use the given number of clock cycles in HDL and SPICE simulations.
+
+- ``slack="<float>"``
+  add a margin to the critical path delay in the HDL and SPICE simulations.
+  This parameter is applied to the critical path delay provided by VPR STA engine.
+  So it is only valid when option ``frequency`` is set to ``auto``.
+  This aims to compensate any inaccuracy in STA results.
+  Typically, the slack value is between ``0`` and ``1``. 
+  For example, ``slack=0.2`` implies that the actual clock period in simulations is 120% of the critical path delay reported by VPR. 
+
+.. note:: Only valid when option ``frequency`` is set to ``auto``
+
+.. warning:: Avoid to use a negative slack! This may cause your simulation to fail!
+
+Programming clock setting
+`````````````````````````
+Programming clocks are defined under the XML node ``<programming>``
+
+- ``frequency="<float>"``
+  Specify the frequency of the programming clock using an absolute value in the unit of ``[Hz]`` 
+  This frequency is used in testbenches for programming phase simulation.
+
+.. note:: Programming clock frequency is typically much slower than the operating clock and strongly depends on the process technology. Suggest to characterize the speed of your configuration protocols before specifying a value!
+
+Simulator Option
+^^^^^^^^^^^^^^^^
+This XML node includes universal options available in both HDL and SPICE simulators.
+
+.. note:: This is mainly used by FPGA-SPICE
+
+``<operating_condition temperature="<int>"/>``
+  Specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as 
+
+.. code-block:: python
+
+    .temp <int>
+
+``<output_log verbose="<bool>" captab="<bool>"/>``
+  Specify the options in outputting simulation results to log files
+
+- ``verbose="true|false"``
+
+  Specify if the simulation waveforms should be printed out after SPICE simulations. If turned on, it will show in all the SPICE netlists
+
+.. code-block:: python
+  
+  .option POST
+
+.. note:: when the SPICE netlists are large or a long simulation duration is defined, the post option is recommended to be off. If not, huge disk space will be occupied by the waveform files.
+
+- ``captab="true|false"``
+  Specify if the capacitances of all the nodes in the SPICE netlists will be printed out. If turned on, it will show inn the top-level SPICE netlists
+
+.. code-block:: python
+
+  .option CAPTAB 
+
+.. note:: When turned on, the SPICE simulation runtime may increase.
+
+``<accuracy type="<string>" value="<float>"/>``
+  Specify the simulation steps (accuracy) to be used
+
+- ``type="abs|frac"``
+
+  Specify the type of transient step in SPICE simulation. 
+
+    * When ``abs`` is selected, the accuracy should be the absolute value, such as ``1e-12``. 
+
+    * When ``frac`` is selected, the accuracy is the number of simulation points in a clock cycle period, for example, 100.
     
+- ``value="<float>"``
+
+  Specify the transient step in SPICE simulation. Typically, the smaller the step is, the higher the accuracy that can be reached while the long simulation runtime is. The recommended accuracy is between 0.1ps and 0.01ps, which generates good accuracy and runtime is not significantly long. 
     

docs/source/arch_lang/technology_library.rst

@@ -1,5 +1,7 @@
-Technology library Declaration
-==============================
+.. _technology_library_syntax:
+
+Technology library
+------------------
 
 .. code-block:: xml
 

docs/source/contact.rst

@@ -1,7 +1,7 @@
 .. _contact:
 
 Contact
-=======
+~~~~~~~
    
 General questions:
 

docs/source/fpga_bitstream/index.rst

@@ -1,8 +1,5 @@
-FPGA-Bitstream
-==============
-
 .. _fpga_bitstream:
-   User Manual for FPGA Bitstream Generator
+   FPGA-Bitstream
  
 .. toctree::
    :maxdepth: 2

docs/source/fpga_spice/index.rst

@@ -1,8 +1,5 @@
-FPGA-SPICE: SPICE Auto-Generation
-====================================
-
 .. _fpga_spice:
-   User Manual for FPGA-SPICE support
+   FPGA-SPICE
  
 .. toctree::
   

docs/source/fpga_verilog/index.rst

@@ -1,8 +1,5 @@
-FPGA-Verilog: Verilog Auto-Generation
--------------------------------------
-
 .. _fpga_verilog:
-   User Manual for FPGA Verilog Generator 
+   FPGA-Verilog
  
 .. toctree::
    :maxdepth: 2

docs/source/index.rst

@@ -19,10 +19,14 @@ Welcome to OpenFPGA's documentation!
 
 .. toctree::
    :maxdepth: 2
-   :caption: Tools Guide
+   :caption: Architecture Description Language
 
    arch_lang/index
 
+.. toctree::
+   :maxdepth: 2
+   :caption: OpenFPGA Tools
+
    fpga_spice/index
 
    fpga_verilog/index

docs/source/motivation.rst

@@ -1,5 +1,5 @@
-Motivation
-==========
+Why OpenFPGA?
+-------------
 
 OpenFPGA aims to be an open-source framework that enables rapid prototyping of customizable FPGA architectures. As shown in :numref:`fig_openfpga_motivation`, a conventional approach will take a large group of experienced engineers more than one year to achieve production-ready layout and assoicated CAD tools. In fact, most of the engineering efforts are spent on manual layouts and developing ad-hoc CAD support.
 
@@ -29,7 +29,7 @@ The rest of this section will focus on detailed motivation on each of them, as d
 
 
 FPGA-Verilog
-------------
+~~~~~~~~~~~~
 
 Driven by the strong need in data processing applications, Field Programmable Gate Arrays (FPGAs) are playing an ever-increasing role as programmable accelerators in modern
 computing systems. To fully unlock processing capabilities for domain-specific applications, FPGA architectures have to be tailored for seamless cooperation with other computing resources. However, prototyping and bringing to production a customized FPGA is a costly and complex endeavor even for industrial vendors. OpenFPGA, an opensource framework, aims to rapid prototype of customizable FPGA architectures through a semi-custom design approach. We propose an XML-to-Prototype design flow, where the Verilog netlists of a full FPGA fabric can be autogenerated using an extension of the XML language from the VTR framework and then fed into a back-end flow to generate production-ready layouts. 
@@ -37,7 +37,7 @@ computing systems. To fully unlock processing capabilities for domain-specific a
 The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.
 
 FPGA-SDC
---------
+~~~~~~~~
 
 Design constraints are indepensible in modern ASIC design flows to guarantee the performance level.
 OpenFPGA includes a rich SDC generator in the OpenFPGA framework to deal with both PnR constraints and sign-off timing analysis.
@@ -47,7 +47,7 @@ The technical details can be found in our FPL'19 paper :cite:`XTang_FPL_2019`.
 
 
 FPGA-Bitstream
---------------
+~~~~~~~~~~~~~~
 
 EDA support is essential for end-users to implement designs on a customized FPGA. OpenFPGA provides a general-purpose bitstream generator FPGA-Bitstream for any architecture that can be described by VPR. As the native CAD tool for any customized FPGA that is produced by FPGA-Verilog, FPGA-Bitstream is ready to use once users finalize the XML-based architecture description file. This eliminates the huge engineering efforts spent on developing bitstream generator for customized FPGAs.
 
@@ -56,7 +56,7 @@ Using FPGA-Bitstream, users can launch (1) Verilog-to-Bitstream flow. This is th
 The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.
 
 FPGA-SPICE
-----------
+~~~~~~~~~~
 
 The built-in timing and power analysis engines of VPR are based on analytical models :cite:`VBetz_Book_1999,JGoeders_FPT_2012`. Analytical model-based analysis can promise accuracy only on a limited number of circuit designs for which the model is valid. As the technology advancements create more opportunities on circuit designs and FPGA architectures, the analytical power model require to be updated to follow the new trends. However, without referring to simulation results, the analytical power models cannot prove their accuracy. SPICE simulators have the advantages of generality and accuracy over analytical models. For this reason, SPICE simulation results are often selected to check the accuracy of analytical models. Therefore, there is a strong need for a simulation-based power analysis approach for FPGAs, which can support general circuit designs.
 

docs/source/tutorials/compile.rst

@@ -1,8 +1,10 @@
-How to Compile
-==============
+.. _compile:
 
-General Compilation Guidelines
-------------------------------
+How to Compile
+--------------
+
+General Guidelines
+~~~~~~~~~~~~~~~~~~
 OpenFPGA uses CMake to generate the Makefile scripts
 In general, please follow the steps to compile
 
@@ -29,7 +31,7 @@ To quickly verify the tool is well compiled, user can run the following command
   python3 openfpga_flow/scripts/run_fpga_task.py compilation_verification --debug --show_thread_logs
 
 Dependencies
-------------
+~~~~~~~~~~~~
 Full list of dependencies can be found at travis_setup_link_
 In particular, OpenFPGA requires specific versions for the following dependencies:
 
@@ -42,7 +44,7 @@ In particular, OpenFPGA requires specific versions for the following dependencie
 .. _travis_setup_link: https://github.com/LNIS-Projects/OpenFPGA/blob/0cfb88a49f152aab0a06f309ff160f222bb51ed7/.travis.yml#L34
 
 Docker
-------
+~~~~~~
 If some of these dependencies are not installed on your machine, you can choose to use a Docker (the Docker tool needs to be installed).
 For the ease of the customer first experience, a Dockerfile is provided in the OpenFPGA folder. A container ready to use can be created with the following command
 

docs/source/tutorials/eda_flow.rst

@@ -1,5 +1,7 @@
-EDA flow
-========
+.. _eda_flow:
+
+Supported EDA flows in OpenFPGA
+-------------------------------
 
 As illustrated in :numref:`fig_eda_flow`, FPGA-SPICE creates a modified VTR flow. All the input files for VPR do not need modifications except the architecture description XML. As simulation-based power analysis requires the transistor-level netlists, we extend the architecture description language to support transistor-level modeling (See details in "Tools Guide>Extended Architecture Description Language"). FPGA-SPICE, embedded in VPR, outputs the SPICE netlists and testbenches according to placement and routing results when enabled by command-line options. (See each "FPGA-*Branch*" about command-line options available) Besides automatically generating all the SPICE netlists, FPGA-SPICE supports user-defined SPICE netlists for modules. We believe the support on user-defined SPICE netlists allows FPGA-SPICE to be general enough to support novel circuit designs and even technologies. (See "FPGA-SPICE... > Create Customized SPICE Modules" for guidelines in customizing your FPGA-SPICE compatible SPICE netlists.) With the dumped SPICE netlists and testbenches, a SPICE simulator, i.e., HSPICE, can be called to conduct a power analysis. FPGA-SPICE automatically generates a shell script, which brings convenience for users to run all the simulations (See "FPGA-SPICE... > Run SPICE simulation").