Support of multiple regions for configuration chain

.travis/basic_reg_test.sh

@@ -17,9 +17,11 @@ python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/config
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/configuration_chain_use_set --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/configuration_chain_use_setb --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/configuration_chain_use_set_reset --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/multi_region_configuration_chain --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/fast_configuration_chain --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/fast_configuration_chain_use_set --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/smart_fast_configuration_chain --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/full_testbench/smart_fast_multi_region_configuration_chain --debug --show_thread_logs
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/preconfig_testbench/configuration_chain --debug --show_thread_logs
 
 echo -e "Testing fram-based configuration protocol of a K4N4 FPGA";
@@ -64,6 +66,15 @@ python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/generate_testbench --
 echo -e "Testing user-defined simulation settings: clock frequency and number of cycles";
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fixed_simulation_settings --debug --show_thread_logs
 
+echo -e "Testing Secured FPGA fabrics";
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/generate_vanilla_key --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/generate_multi_region_vanilla_key --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/generate_random_key --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/load_external_key --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/load_external_key_cc_fpga --debug --show_thread_logs
+python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/fabric_key/load_external_key_multi_region_cc_fpga --debug --show_thread_logs
+
+
 echo -e "Testing K4 series FPGA";
 echo -e "Testing K4N4 with facturable LUTs";
 python3 openfpga_flow/scripts/run_fpga_task.py basic_tests/k4_series/k4n4_frac_lut --debug --show_thread_logs

.travis/fpga_verilog_reg_test.sh

@@ -82,10 +82,6 @@ python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/duplicated_grid_pin
 echo -e "Testing Verilog generation with spy output pads";
 python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/spypad --debug --show_thread_logs
 
-echo -e "Testing Secured FPGA fabrics";
-python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/fabric_key/generate_vanilla_key --debug --show_thread_logs
-python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/fabric_key/generate_random_key --debug --show_thread_logs
-python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/fabric_key/load_external_key --debug --show_thread_logs
 
 echo -e "Testing Power-gating designs";
 python3 openfpga_flow/scripts/run_fpga_task.py fpga_verilog/power_gated_design/power_gated_inverter --show_thread_logs --debug

docs/source/manual/arch_lang/config_protocol.rst

@@ -49,7 +49,7 @@ It will use the circuit model defined in :numref:`fig_ccff`.
 .. code-block:: xml
 
   <configuration_protocol>
-    <organization type="scan_chain" circuit_model_name="ccff"/>
+    <organization type="scan_chain" circuit_model_name="ccff" num_regions="<int>"/>
   </configuration_protocol>
 
 .. _fig_ccff_fpga:
@@ -60,6 +60,17 @@ It will use the circuit model defined in :numref:`fig_ccff`.
 
    Example of a configuration chain to program core logic of a FPGA 
 
+.. option:: num_regions="<int>"
+
+  Specify the number of configuration chains to be used across the fabrics. By default, it will be only 1 configuration chain. The more configuration chain to be used, the fast configuration runtime will be, but at the cost of more I/Os in the FPGA fabrics. The organization of each configurable region can be customized through the fabric key (see details in :ref:`fabric_key`).
+
+.. figure:: figures/multi_region_config_chains.png
+   :scale: 100%
+   :alt: map to buried treasure
+
+   Examples of single- and multiple- region configuration chains
+
+
 Frame-based Example
 ~~~~~~~~~~~~~~~~~~~
 The following XML code describes frame-based memory banks to configure the core logic of FPGA.

docs/source/manual/arch_lang/fabric_key.rst

@@ -1,3 +1,5 @@
+.. _fabric_key:
+
 Fabric Key
 ~~~~~~~~~~
 
@@ -6,6 +8,12 @@ With this key, OpenFPGA can generate correct bitstreams for the FPGA.
 Using a wrong key, OpenFPGA may error out or generate wrong bitstreams.
 The fabric key support allows users to build secured/classified FPGA chips even with an open-source tool.
 
+.. figure:: figures/fabric_key_motivation.png
+   :scale: 60%
+   :alt: map to buried treasure
+
+   The use of fabric key to secure the FPGA chip design
+
 .. note:: Users are the only owner of the key. OpenFPGA will not store or replicate the key.
 
 Key Generation
@@ -19,7 +27,56 @@ A fabric key can be achieved in the following ways:
 File Format
 ```````````
 
-A fabric key follows an XML format. As shown in the following XML code, the key file includes the organization of configurable memory blocks in the top-level FPGA fabric: 
+A fabric key follows an XML format. As shown in the following XML code, the key file includes the organization of configurable blocks in the top-level FPGA fabric. 
+
+Configurable Region
+^^^^^^^^^^^^^^^^^^^
+
+The top-level FPGA fabric can consist of several configurable regions, where a region may contain one or multiple configurable blocks. Each configurable region can be configured independently and in parrallel.
+
+.. option:: <region id="<int>"/>
+
+  - ``id`` indicates the unique id of a configurable region in the fabric.
+
+  .. warning:: The id must start from zero!
+
+  .. note:: The number of regions defined in the fabric key must be consistent with the number of regions defined in the configuration protocol of architecture description. (See details in :ref:`config_protocol`).
+
+The following example shows how to define multiple configuration regions in the fabric key.
+
+.. code-block:: xml
+
+  <fabric_key>
+    <region id="0">
+      <key id="0" name="grid_io_bottom" value="0" alias="grid_io_bottom_1__0_"/>
+      <key id="1" name="grid_io_right" value="0" alias="grid_io_right_2__1_"/>
+      <key id="2" name="sb_1__1_" value="0" alias="sb_1__1_"/>
+    </region>
+    <region id="1">
+      <key id="3" name="cbx_1__1_" value="0" alias="cbx_1__1_"/>
+      <key id="4" name="grid_io_top" value="0" alias="grid_io_top_1__2_"/>
+      <key id="5" name="sb_0__1_" value="0" alias="sb_0__1_"/>
+    </region>
+    <region id="2">
+      <key id="6" name="sb_0__0_" value="0" alias="sb_0__0_"/>
+      <key id="7" name="cby_0__1_" value="0" alias="cby_0__1_"/>
+      <key id="8" name="grid_io_left" value="0" alias="grid_io_left_0__1_"/>
+    </region>
+    <region id="3">
+      <key id="9" name="sb_1__0_" value="0" alias="sb_1__0_"/>
+      <key id="10" name="cbx_1__0_" value="0" alias="cbx_1__0_"/>
+      <key id="11" name="cby_1__1_" value="0" alias="cby_1__1_"/>
+      <key id="12" name="grid_clb" value="0" alias="grid_clb_1__1_"/>
+    </region>
+  </fabric_key>
+
+
+Configurable Block
+^^^^^^^^^^^^^^^^^^^
+
+Each configurable block is defined as a key. There are two ways to define a key, either with alias or with name and value. 
+
+.. option:: <key id="<int>" alias="<string>" name="<string>" value="<int>"/>
 
   - ``id`` indicates the sequence of the configurable memory block in the top-level FPGA fabric.
 
@@ -29,86 +86,92 @@ A fabric key follows an XML format. As shown in the following XML code, the key
 
   - ``alias`` indicates the instance name of the configurable memory block in the top-level FPGA fabric. If a valid alias is specified, the ``name`` and ``value`` are not required.
 
-.. note:: For fast loading of fabric key, strongly recommend to use pairs ``name`` and ``alias`` or ``name`` and ``value`` in the fabric key file. Using only ``alias`` may cause long parsing time for fabric key. 
+.. warning:: For fast loading of fabric key, strongly recommend to use pairs ``name`` and ``alias`` or ``name`` and ``value`` in the fabric key file. Using only ``alias`` may cause long parsing time for fabric key. 
 
 The following is an example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
 This key contains only ``alias`` which is easy to craft.
 
 .. code-block:: xml
 
-    <fabric_key>
-    	<key id="0" alias="sb_2__2_"/>
-    	<key id="1" alias="grid_clb_2_2"/>
-    	<key id="2" alias="sb_0__1_"/>
-    	<key id="3" alias="cby_0__1_"/>
-    	<key id="4" alias="grid_clb_2_1"/>
-    	<key id="5" alias="grid_io_left_0_1"/>
-    	<key id="6" alias="sb_1__0_"/>
-    	<key id="7" alias="sb_1__1_"/>
-    	<key id="8" alias="cbx_2__1_"/>
-    	<key id="9" alias="cby_1__2_"/>
-    	<key id="10" alias="grid_io_right_3_2"/>
-    	<key id="11" alias="cbx_2__0_"/>
-    	<key id="12" alias="cby_1__1_"/>
-    	<key id="13" alias="grid_io_right_3_1"/>
-    	<key id="14" alias="grid_io_bottom_1_0"/>
-    	<key id="15" alias="cby_2__1_"/>
-    	<key id="16" alias="sb_2__1_"/>
-    	<key id="17" alias="cbx_1__0_"/>
-    	<key id="18" alias="grid_clb_1_2"/>
-    	<key id="19" alias="cbx_1__2_"/>
-    	<key id="20" alias="cbx_2__2_"/>
-    	<key id="21" alias="sb_2__0_"/>
-    	<key id="22" alias="sb_1__2_"/>
-    	<key id="23" alias="cby_0__2_"/>
-    	<key id="24" alias="sb_0__0_"/>
-    	<key id="25" alias="grid_clb_1_1"/>
-    	<key id="26" alias="cby_2__2_"/>
-    	<key id="27" alias="grid_io_top_2_3"/>
-    	<key id="28" alias="sb_0__2_"/>
-    	<key id="29" alias="grid_io_bottom_2_0"/>
-    	<key id="30" alias="cbx_1__1_"/>
-    	<key id="31" alias="grid_io_top_1_3"/>
-    	<key id="32" alias="grid_io_left_0_2"/>
-    </fabric_key>
+  <fabric_key>
+    <region id="0">
+      <key id="0" alias="sb_2__2_"/>
+      <key id="1" alias="grid_clb_2_2"/>
+      <key id="2" alias="sb_0__1_"/>
+      <key id="3" alias="cby_0__1_"/>
+      <key id="4" alias="grid_clb_2_1"/>
+      <key id="5" alias="grid_io_left_0_1"/>
+      <key id="6" alias="sb_1__0_"/>
+      <key id="7" alias="sb_1__1_"/>
+      <key id="8" alias="cbx_2__1_"/>
+      <key id="9" alias="cby_1__2_"/>
+      <key id="10" alias="grid_io_right_3_2"/>
+      <key id="11" alias="cbx_2__0_"/>
+      <key id="12" alias="cby_1__1_"/>
+      <key id="13" alias="grid_io_right_3_1"/>
+      <key id="14" alias="grid_io_bottom_1_0"/>
+      <key id="15" alias="cby_2__1_"/>
+      <key id="16" alias="sb_2__1_"/>
+      <key id="17" alias="cbx_1__0_"/>
+      <key id="18" alias="grid_clb_1_2"/>
+      <key id="19" alias="cbx_1__2_"/>
+      <key id="20" alias="cbx_2__2_"/>
+      <key id="21" alias="sb_2__0_"/>
+      <key id="22" alias="sb_1__2_"/>
+      <key id="23" alias="cby_0__2_"/>
+      <key id="24" alias="sb_0__0_"/>
+      <key id="25" alias="grid_clb_1_1"/>
+      <key id="26" alias="cby_2__2_"/>
+      <key id="27" alias="grid_io_top_2_3"/>
+      <key id="28" alias="sb_0__2_"/>
+      <key id="29" alias="grid_io_bottom_2_0"/>
+      <key id="30" alias="cbx_1__1_"/>
+      <key id="31" alias="grid_io_top_1_3"/>
+      <key id="32" alias="grid_io_left_0_2"/>
+    </region>
+  </fabric_key>
 
 The following shows another example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
 This key contains only ``name`` and ``value`` which is fast to parse.
 
 .. code-block:: xml
 
-    <fabric_key>
-    	<key id="0" name="sb_2__2_" value="0"/>
-    	<key id="1" name="grid_clb" value="3"/>
-    	<key id="2" name="sb_0__1_" value="0"/>
-    	<key id="3" name="cby_0__1_" value="0"/>
-    	<key id="4" name="grid_clb" value="2"/>
-    	<key id="5" name="grid_io_left" value="0"/>
-    	<key id="6" name="sb_1__0_" value="0"/>
-    	<key id="7" name="sb_1__1_" value="0"/>
-    	<key id="8" name="cbx_1__1_" value="1"/>
-    	<key id="9" name="cby_1__1_" value="1"/>
-    	<key id="10" name="grid_io_right" value="1"/>
-    	<key id="11" name="cbx_1__0_" value="1"/>
-    	<key id="12" name="cby_1__1_" value="0"/>
-    	<key id="13" name="grid_io_right" value="0"/>
-    	<key id="14" name="grid_io_bottom" value="0"/>
-    	<key id="15" name="cby_2__1_" value="0"/>
-    	<key id="16" name="sb_2__1_" value="0"/>
-    	<key id="17" name="cbx_1__0_" value="0"/>
-    	<key id="18" name="grid_clb" value="1"/>
-    	<key id="19" name="cbx_1__2_" value="0"/>
-    	<key id="20" name="cbx_1__2_" value="1"/>
-    	<key id="21" name="sb_2__0_" value="0"/>
-    	<key id="22" name="sb_1__2_" value="0"/>
-    	<key id="23" name="cby_0__1_" value="1"/>
-    	<key id="24" name="sb_0__0_" value="0"/>
-    	<key id="25" name="grid_clb" value="0"/>
-    	<key id="26" name="cby_2__1_" value="1"/>
-    	<key id="27" name="grid_io_top" value="1"/>
-    	<key id="28" name="sb_0__2_" value="0"/>
-    	<key id="29" name="grid_io_bottom" value="1"/>
-    	<key id="30" name="cbx_1__1_" value="0"/>
-    	<key id="31" name="grid_io_top" value="0"/>
-    	<key id="32" name="grid_io_left" value="1"/>
-    </fabric_key>
+  <fabric_key>
+    <region id="0">
+      <key id="0" name="sb_2__2_" value="0"/>
+      <key id="1" name="grid_clb" value="3"/>
+      <key id="2" name="sb_0__1_" value="0"/>
+      <key id="3" name="cby_0__1_" value="0"/>
+      <key id="4" name="grid_clb" value="2"/>
+      <key id="5" name="grid_io_left" value="0"/>
+      <key id="6" name="sb_1__0_" value="0"/>
+      <key id="7" name="sb_1__1_" value="0"/>
+      <key id="8" name="cbx_1__1_" value="1"/>
+      <key id="9" name="cby_1__1_" value="1"/>
+      <key id="10" name="grid_io_right" value="1"/>
+      <key id="11" name="cbx_1__0_" value="1"/>
+      <key id="12" name="cby_1__1_" value="0"/>
+      <key id="13" name="grid_io_right" value="0"/>
+      <key id="14" name="grid_io_bottom" value="0"/>
+      <key id="15" name="cby_2__1_" value="0"/>
+      <key id="16" name="sb_2__1_" value="0"/>
+      <key id="17" name="cbx_1__0_" value="0"/>
+      <key id="18" name="grid_clb" value="1"/>
+      <key id="19" name="cbx_1__2_" value="0"/>
+      <key id="20" name="cbx_1__2_" value="1"/>
+      <key id="21" name="sb_2__0_" value="0"/>
+      <key id="22" name="sb_1__2_" value="0"/>
+      <key id="23" name="cby_0__1_" value="1"/>
+      <key id="24" name="sb_0__0_" value="0"/>
+      <key id="25" name="grid_clb" value="0"/>
+      <key id="26" name="cby_2__1_" value="1"/>
+      <key id="27" name="grid_io_top" value="1"/>
+      <key id="28" name="sb_0__2_" value="0"/>
+      <key id="29" name="grid_io_bottom" value="1"/>
+      <key id="30" name="cbx_1__1_" value="0"/>
+      <key id="31" name="grid_io_top" value="0"/>
+      <key id="32" name="grid_io_left" value="1"/>
+    </region>
+  </fabric_key>
+
+

docs/source/manual/fpga_verilog/testbench.rst

@@ -88,7 +88,7 @@ Inside the directory, the Verilog testbenches are organized as illustrated in :n
 .. _fig_preconfig_module:
 
 .. figure:: ./figures/preconfig_module.png
-   :scale: 100%
+   :scale: 25%
 
    Internal structure of a pre-configured FPGA module
 

docs/source/motivation.rst

@@ -27,12 +27,43 @@ The rest of this section will focus on detailed motivation on each of them, as d
 
    Design flows in different purposes using OpenFPGA
 
+Fully Customizable Architecture
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+OpenFPGA supports VPR's architecture description language, which allows 
+users to define versatile programmable fabrics down to point-to-point 
+interconnection.
+OpenFPGA leverage VPR's architecture description by introducing an XML-based 
+architecture annotation, enabling fully customizable FPGA fabric down to 
+circuit elements.
+As illustrated in :ref:`fig_openfpga_arch_lang_coverage`, OpenFPGA's 
+architecture annotation covers a complete FPGA fabric, including both the 
+programmable fabric and the configuration peripheral.
+
+.. _fig_openfpga_arch_lang_coverage:
+
+.. figure:: ./figures/openfpga_arch_lang_coverage.png
+   :scale: 15%
+   :alt: OpenFPGA architecture description language enabling fully customizable FPGA architecture and circuit-level implementation
+
+   OpenFPGA architecture description language enabling fully customizable FPGA architecture and circuit-level implementation
+
+The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.
 
 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. 
+FPGA-Verilog is designed to output flexible and standard Verilog netlists, enabling various backend choices, as illustrated in :ref:`fig_fpga_verilog_motivation`.
+
+.. _fig_fpga_verilog_motivation:
+
+.. figure:: ./figures/fpga_verilog_motivation.png
+   :scale: 25%
+   :alt: Flexible netlist format support by FPGA-Verilog to enable various backend choices
+
+   FPGA-Verilog enabling flexible backend flows
 
 The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.
 
@@ -41,7 +72,18 @@ 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.
-Our flow automatically generates two sets of SDC files. The first set of SDC is designed for the P&R flow, where all the combinational loops are broken to enable wellcontrolled timing-driven P&R. In addition, there are SDC files devoted to constrain pin-to-pin timing for all the resources in FPGAs, in order to obtain nicely constrained and homogeneous delays across the fabric. The second set of SDC is designed for the timing analysis of a benchmark at the post P&R stage.
+Our flow automatically generates two sets of SDC files.
+- The first set of SDC is designed for the P&R flow, where all the combinational loops are broken to enable wellcontrolled timing-driven P&R. In addition, there are SDC files devoted to constrain pin-to-pin timing for all the resources in FPGAs, in order to obtain nicely constrained and homogeneous delays across the fabric. OpenFPGA allows users to define timing constraints in the architecture description and outputs timing constraints in standard format, enabling fully timing constrained backend flow (see :ref:`fig_fpga_sdc_motivation`).
+- The second set of SDC is designed for the timing analysis of a benchmark at the post P&R stage.
+
+.. _fig_fpga_sdc_motivation:
+
+.. figure:: ./figures/fpga_sdc_motivation.png
+   :scale: 25%
+   :alt: FPGA-SDC enabling iterative timing constrained backend flow
+
+   FPGA-SDC enabling iterative timing constrained backend flow
+
 
 The technical details can be found in our FPL'19 paper :cite:`XTang_FPL_2019`.