remove obselete vpr7 XML syntax from documentation
This commit is contained in:
tangxifan
parent
cb0df2c1c6
commit
862d71f57a
|
|
@ -3,124 +3,6 @@
|
|||
Circuit Library
|
||||
---------------
|
||||
|
||||
For OpenFPGA using VPR7
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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.
|
||||
|
||||
Circuit Model Attributes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<module_circuit_models>
|
||||
<circuit_model type="string" name="string" prefix="string" is_default="int"
|
||||
circuit_netlist="string" verilog_netlist="string" dump_structural_verilog="string">
|
||||
<transistor-level circuit_design_features="developped_further" />
|
||||
</circuit_model>
|
||||
</module_circuit_models>
|
||||
|
||||
* **module_circuit_models**: the father node for all the circuit models. All the circuit models should be defined under this XML node.
|
||||
|
||||
* **circuit_model**: the child node defining transistor-level modeling parameters.
|
||||
|
||||
* **type**: can be [ ``inv_buf`` | ``pass_gate`` | ``gate`` | ``mux`` | ``wire`` | ``chan_wire`` | ``sram`` | ``lut`` | ``ff`` | ``scff`` | ``hard_logic`` | ``iopad`` ]. Specify the type of circuit model. The provided types cover all the modules in FPGAs. For the circuit models in the type of mux/wire/chan_wire/lut, FPGA-Verilog/SPICE can auto-generate Verilog/SPICE netlists. For the rest, FPGA-Verilog/SPICE requires a user-defined Verilog/SPICE netlist.
|
||||
|
||||
* **name**: define the name of this circuit model. The name should be unique and will be used to create the sub-circuit of the circuit model in Verilog/SPICE netlists. Note that for a customized Verilog/SPICE netlist, the name defined here should be the name of the top-level sub-circuit in the customized Verilog/SPICE netlist. FPGA-Verilog/SPICE will check if the given name is conflicted with any reserved words.
|
||||
|
||||
* **prefix**: specify the name of the circuit_model to shown in the auto-generated Verilog/SPICE netlists. The prefix can be the same as the name defined above. And again, the prefix should be unique.
|
||||
|
||||
* **is_default**: can be [``1`` | ``0``], corresponding to [``true`` | ``false``] respectively. Specify this circuit model is the default one for some modules, such as multiplexers. If a module is not linked to any circuit model by users, FPGA-Verilog/SPICE will find the default circuit model defined in the same type and link. For a circuit model type, only one circuit model can be set as default.
|
||||
|
||||
* **circuit_netlist**: specify the path and file name of a customized Verilog/SPICE netlist. For some modules such as SRAMs, FFs, inpads, and outpads, FPGA-Verilog/SPICE does not support auto-generation of the transistor-level sub-circuits because their circuit design is highly dependent on the technology nodes. These circuit designs should be specified by users. For the other modules that can be auto-generated by FPGA-Verilog/SPICE, the user can also define a custom netlist. Multiplexers cannot be user-defined.
|
||||
|
||||
* **verilog_netlist**: specify the path and file name of a customized Verilog netlist. For some modules such as SRAMs, FFs, inpad and outpads, FPGA-Verilog/SPICE does not support auto-generation of the transistor-level sub-circuits because their circuit design is highly dependent on the technology nodes. These circuit designs should be specified by users. For the other modules that can be auto-generated by FPGA-Verilog/SPICE, the user can also define a custom netlist. Multiplexers cannot be user-defined.
|
||||
|
||||
* **dump_structural_verilog**: when the value of this keyword is set to be true, Verilog generator will output gate-level netlists of this module, instead of behavior-level. Gate-level netlists bring more opportunities in layout-level optimization while behavior-level is more suitable for high-speed formal verification and easier in debugging with HDL simulators.
|
||||
|
||||
.. note:: If netlist is not specified, FPGA-Verilog/SPICE auto-generates the Verilog/SPICE netlists for multiplexers, wires, and LUTs.
|
||||
|
||||
.. note:: The user-defined netlists, such as LUTs, the decoding methodology should comply with the auto-generated LUTs (See Section 4.5)
|
||||
|
||||
.. 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.
|
||||
|
||||
|
||||
Design Technology-related Attributes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="string" name="string" prefix="string" is_default="int" netlist="string"
|
||||
dump_structural_verilog="string">
|
||||
<design_technology type="string"/>
|
||||
<device_technology device_model_name="string"/>
|
||||
<input_buffer exist="string" circuit_model_name="string"/>
|
||||
<output_buffer exist="string" circuit_model_name="string"/>
|
||||
<pass_gate_logic type="string" circuit_model_name="string"/>
|
||||
<port type="string" prefix="string" lib_name="string" size="int" default_val="int" circuit_model_name="string"
|
||||
mode_select="boolean" is_global="boolean" is_set="boolean" is_reset="boolean"
|
||||
is_config_enable="boolean"/>
|
||||
</circuit_model>
|
||||
|
||||
* design_technology :
|
||||
|
||||
* **type:** [cmos|rram]. Specify the type of design technology of the circuit_model.
|
||||
|
||||
.. note:: Currently, the RRAM-based designs are only supported for multiplexers.
|
||||
|
||||
|
||||
Device Technology-related Attributes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* device_model_name : Specify the name of device model that the circuit design will use. The device model must be defined in the technology library (see details in :ref:technology_library);
|
||||
|
||||
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.
|
||||
|
||||
* **circuit_model_name:** Specify the name of circuit model which is used to implement input/output buffer, the type of specified circuit model should be inv_buf.
|
||||
|
||||
* pass_gate_logic: defined the parameters in pass-gates, which are used in building multiplexers and LUTs.
|
||||
|
||||
* **circuit_model_name:** Specify the name of the circuit model which is used to implement transmission gate, the type of specified circuit model should be pass_gate.
|
||||
|
||||
* port: define the port list of a circuit model.
|
||||
|
||||
* **type:** can be [input|output|sram|clock]. For programmable modules, such as multiplexers and LUTs, SRAM ports should be defined. For registers, such as FFs and memory banks, clock ports should be defined.
|
||||
|
||||
* **prefix:** the name of the port to appear in the autogenerated netlists. Each port will be shown as ``<prefix>[i]`` in Verilog/SPICE netlists.
|
||||
|
||||
* **lib_name:** the name of the port defined in standard cells or customized cells. If not specified, this attribute will be the same as ``prefix``.
|
||||
|
||||
* **size:** bandwidth of the port.
|
||||
|
||||
* **default_val:** default logic value of a port, which is used as the initial logic value of this port in testbench generation. Can be either 0 or 1. We assume each pin of this port has the same default value.
|
||||
|
||||
* **circuit_model_name:** only valid when the type of port is sram. Specify the name of the circuit model which is connected to this port.
|
||||
|
||||
* **mode_select:** can be either ``true`` or ``false``. Specify if this port controls the mode switching in a configurable logic block. Only valid when the type of this port is sram. (A configurable logic block can operate in different modes, which is controlled by SRAM bits.)
|
||||
|
||||
* **is_global:** can be either ``true`` or ``false``. Specify if this port is a global port, which will be routed globally. Note that when multiple global ports are defined with the same name, these global ports will be short-wired together.
|
||||
|
||||
* **is_set:** can be either ``true`` or ``false``. Specify if this port controls a set signal. Only valid when ``is_global`` is true. All the set ports are connected to global set voltage stimuli in testbenches.
|
||||
|
||||
* **is_reset:** can be either ``true`` or ``false``. Specify if this port controls a reset signal. Only valid when ``is_global`` is true. All the reset ports are connected to a global reset voltage stimuli in testbenches.
|
||||
|
||||
* **is_config_enable:** can be either ``true`` or ``false``. Only valid when ``is_global`` is true. Specify if this port controls a configuration-enable signal. This port is only enabled during FPGA configuration, and always disabled during FPGA operation. All the ``config_enable`` ports are connected to global configuration-enable voltage stimuli in testbenches.
|
||||
|
||||
.. note:: Different types of ``circuit_model`` have different XML syntax, with which users can highly customize their circuit topologies. See refer to examples of ``circuit_model`` for more details.
|
||||
|
||||
.. note:: Note that we have a list of reserved port names, which indicate the usage of these ports when building FPGA fabrics. Please do not use ``mem_out``, ``mem_inv``, ``bl``, ``wl``, ``blb``, ``wlb``, ``ccff_head`` and ``ccff_tail``.
|
||||
|
||||
For OpenFPGA using VPR8
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Circuit design is a dominant factor in Power, Performance, Area (P.P.A.) of FPGA fabrics.
|
||||
Upon practical applications, the hardware engineers may select various circuits to implement their FPGA fabrics.
|
||||
For instance, a ultra-low-power FPGA may be built with ulta-low-power circuit cells while a high-performance FPGA may use absolutely different circuit cells.
|
||||
|
|
@ -219,7 +101,7 @@ Design Technology
|
|||
Device Technology
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. option:: <device_technology device_model_name="string"/>
|
||||
.. option:: <device_technology device_model_name="<string>"/>
|
||||
|
||||
Specify the technology binding between a circuit model and a device model which is defined in the technology library (see details in :ref:`technology_library`).
|
||||
|
||||
|
|
|
|||
|
|
@ -3,16 +3,6 @@
|
|||
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 separated XMLs 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.
|
||||
|
|
|
|||
|
|
@ -3,144 +3,6 @@
|
|||
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.
|
||||
|
||||
* The XML node <options>
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<options sim_temp=”int” post=”string”captab=”string” fast=”string”/>
|
||||
|
||||
These properties define the options that will be printed in the top SPICE netlists.
|
||||
|
||||
* **sim_temp:** specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as .temp <int>.
|
||||
|
||||
* **post:** [on|off]. Specify if the simulation waveforms should be printed out after SPICE simulations. In all the SPICE netlists, it will show as .option POST when turned on.
|
||||
|
||||
.. 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:** [on|off]. Specify if the capacitances of all the nodes in the SPICE netlists will be printed out. In the top SPICE netlists, it will show as .option CAPTAB when turned on. When turned on, the SPICE simulation runtime may increase.
|
||||
|
||||
* The XML node <stimulate>
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<stimulate>
|
||||
<clock op_freq=”auto|float” sim_slack=”float” prog_freq=”float”>
|
||||
<rise slew_time=”float” slew_type=”string”/>
|
||||
<fall slew_time=”float” slew_type=”string”/>
|
||||
</clock>
|
||||
</stimulate>
|
||||
|
||||
Define stimulates for the clock signal.
|
||||
|
||||
* **op_freq:** either auto or a float number (unit:[Hz]) Specify the operation clock frequency that is used in SPICE simulations. This frequency is used in testbenches for operation phase simulation. Note that this is a mandatory option. Users have to specify either this frequency is automatically determined by assigning “auto” or give an exact number. If this clock frequency is specified, the sim_slack option is disregarded.
|
||||
|
||||
* **sim_slack:** add slack to the critical path delay in the SPICE simulation. For example, sim_slack=0.2 implies that the clock period in SPICE simulations is 1.2 of the critical path delay reported by VPR. **Only valid when option op_freq is not specified.**
|
||||
|
||||
* **prog_freq:** Specify the programming clock frequency that is used in SPICE simulations. This frequency is used in testbenches for programming phase simulation.
|
||||
|
||||
* **slew_type & slew_time:** define the slew of clock signals at the rising/falling edge. Property slew_type can be either absolute or fractional [abs|frac].
|
||||
|
||||
* The type of **absolute** implies that the slew time is the absolute value. For example, slew_time=20e-12, slew_type=abs means that the slew of a clock signal is 20ps.
|
||||
* The type of **fractional** means that the slew time is related to the period (frequency) of the clock signal. For example, slew_time=0.05, slew_type=frac means that the slew of a clock signal takes 5% of the period of the clock.
|
||||
|
||||
:numref:`fig_meas_edge` depicts the definition of the slew and delays of signals and the parameters that can be supported by FPGA-SPICE.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<stimulate>
|
||||
<input>
|
||||
<rise slew_time=”float” slew_type=”string”/>
|
||||
<fall slew_time=”float” slew_type=”string”/>
|
||||
</input>
|
||||
</stimulate>
|
||||
|
||||
Define the slew of input signals at the rising/falling edge.
|
||||
|
||||
* **slew_type & slew_time:** define the slew of all the input signals at the rising/falling edge. Property slew_type can be either absolute or fractional [abs|frac].
|
||||
|
||||
* The type of **absolute** implies that the slew time is the absolute value. For example, slew_time=20e-12, slew_type=abs means that the slew of a clock signal is 20ps.
|
||||
|
||||
* The type of **fractional** means that the slew time is related to the period (frequency) of the clock signal. For example, slew_time=0.05, slew_type=frac means that the slew of a clock signal takes 5% of the period of the clock.
|
||||
|
||||
.. note:: These slew settings are valid for all the input signals of the testbenches in different complexity levels.
|
||||
|
||||
.. _fig_meas_edge:
|
||||
|
||||
.. figure:: figures/meas_edge.png
|
||||
:scale: 100%
|
||||
:alt: map to buried traesure
|
||||
|
||||
Parameters in measuring the slew and delay of signals
|
||||
|
||||
* The XML node <measure>
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<measure sim_num_clock_cycle=”int”accuracy=”float”accuracy_type=”string”/>
|
||||
|
||||
* **sim_num_clock_cycle:** can be either “auto” or an integer. By setting to “auto”, FPGA-SPICE automatically determines the number of clock cycles to simulate, which is related to the average of all the signal density in ACE2 results. When set to an integer, FPGA-SPICE will use the given number of clock cycles in the SPICE netlists.
|
||||
|
||||
* **accuracy_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.
|
||||
|
||||
* **accuracy:** 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.
|
||||
|
||||
.. note:: Users can define the parameters in measuring the slew of signals, under a child node <slew> of the node <measure>.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<rise upper_thres_pct=”float” lower_thres_pct=”float”/>
|
||||
|
||||
Define the starting and ending point in measuring the slew of a rising edge of a signal.
|
||||
|
||||
* **upper_thres_pct:** the ending point in measuring the slew of a rising edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of upper_thres_pct=0.95 is depicted in Figure 2.
|
||||
|
||||
* **lower_thres_pct:** the starting point in measuring the slew of a rising edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of lower_thres_pct=0.05 is depicted in Figure 2.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<fall upper_thres_pct=”float” lower_thres_pct=”float”/>
|
||||
|
||||
* **upper_thres_pct:** the ending point in measuring the slew of a falling edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of upper_thres_pct=0.05 is depicted in Figure 2.
|
||||
|
||||
* **lower_thres_pct:** the starting point in measuring the slew of a falling edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of lower_thres_pct=0.95 is depicted in Figure 2.
|
||||
|
||||
|
||||
.. note:: Users can define the parameters related to measurements of delays between signals, under a child node <delay> of the node <measure>.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<rise input_thres_pct=”float” output_thres_pct=”float”/>
|
||||
|
||||
Define the starting and ending point in measuring the delay between two signals when they are both at a rising edge.
|
||||
|
||||
* **input_thres_pct:** the starting point in measuring the delay of a rising edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of input_thres_pct=0.5 is depicted in Figure 2.
|
||||
|
||||
* **output_thres_pct:** the ending point in measuring the delay of a rising edge. It is expressed as a percentage of the maximum voltage of a signal. For example, the meaning of output_thres_pct=0.5 is depicted in Figure 2.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<fall input_thres_pct=”float” output_thres_pct=”float”/>
|
||||
|
||||
Define the starting and ending point in measuring the delay between two signals when they are both at a falling edge.
|
||||
|
||||
* **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
|
||||
|
||||
|
|
@ -181,7 +43,7 @@ General organization is as follows
|
|||
</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.
|
||||
|
|
@ -197,7 +59,7 @@ We should the full syntax in the code block below and then provide details on ea
|
|||
</clock_setting>
|
||||
|
||||
Operating clock setting
|
||||
```````````````````````
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Operating clocks are defined under the XML node ``<operating>``
|
||||
|
||||
.. option:: <operating frequency="<float>|<string>" num_cycles="<int>|<string>" slack="<float>"/>
|
||||
|
|
@ -225,7 +87,7 @@ Operating clocks are defined under the XML node ``<operating>``
|
|||
.. 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>``
|
||||
|
||||
.. option:: <programming frequency="<float>"/>
|
||||
|
|
@ -237,13 +99,13 @@ Programming clocks are defined under the XML node ``<programming>``
|
|||
.. 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
|
||||
```````````````````
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. option:: <operating_condition temperature="<int>"/>``
|
||||
|
||||
|
|
@ -255,7 +117,7 @@ Operating condition
|
|||
.temp <int>
|
||||
|
||||
Output logs
|
||||
```````````
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. option:: <output_log verbose="<bool>" captab="<bool>"/>``
|
||||
|
||||
|
|
@ -281,7 +143,7 @@ Output logs
|
|||
.. note:: When turned on, the SPICE simulation runtime may increase.
|
||||
|
||||
Simulation Accuracy
|
||||
```````````````````
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. option:: <accuracy type="<string>" value="<float>"/>``
|
||||
|
||||
|
|
@ -300,7 +162,7 @@ Simulation Accuracy
|
|||
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.
|
||||
|
||||
Simulation Speed
|
||||
````````````````
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. option:: <runtime fast_simulation="<bool>"/>
|
||||
|
||||
|
|
@ -317,7 +179,7 @@ Simulation Speed
|
|||
.option fast
|
||||
|
||||
Monte Carlo Simulation
|
||||
``````````````````````
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. option:: <monte_carlo num_simulation_points="<int>"/>
|
||||
|
||||
|
|
@ -331,7 +193,7 @@ Monte Carlo Simulation
|
|||
The larger the number is, the longer simulation time will be but more accurate the results will be.
|
||||
|
||||
Measurement Setting
|
||||
```````````````````
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
- Users can define the parameters in measuring the slew of signals, under XML node ``<slew>``
|
||||
|
||||
- Users can define the parameters in measuring the delay of signals, under XML node ``<delay>``
|
||||
|
|
@ -355,7 +217,7 @@ Both delay and slew measurement share the same syntax in defining the upper and
|
|||
An illustrative example on measuring the slew and delay of signals
|
||||
|
||||
Stimulus Setting
|
||||
````````````````
|
||||
~~~~~~~~~~~~~~~~
|
||||
Users can define the slew time of input and clock signals to be applied to FPGA I/Os in testbenches under XML node ``<clock>`` and ``<input>`` respectively.
|
||||
This is used by FPGA-SPICE in generating testbenches
|
||||
|
||||
|
|
|
|||
|
|
@ -3,43 +3,6 @@
|
|||
Technology library
|
||||
------------------
|
||||
|
||||
For OpenFPGA using VPR7
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<tech_lib lib_type=”string” transistor_type=”string” lib_path=”string” nominal_vdd=”float”/>
|
||||
|
||||
* **lib_type:** can be either industry or academia [industry|academia]. For the industry library, some transistor types are available, and the type of transistor should be declared in the property transistor_type.
|
||||
|
||||
* **transistor_type:** This XML property specify the transistors to be used in the industry library. For example, the type of transistors can be “TT”, “FF” etc.
|
||||
|
||||
* **lib_path:** specify the path of the library. For example: lib_path=/home/tech/45nm.pm.
|
||||
|
||||
* **nominal_vdd:** specify the working voltage for the technology. The voltage will be used as the supply voltage in all the SPICE netlist.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<transistors pn_ratio=”float” model_ref=”string”/>
|
||||
|
||||
* **pn_ratio:** specify the ratio between p-type transistors and n-type transistors. The ratio will be used when building circuit structures such as inverters, buffers, etc.
|
||||
|
||||
* **model_ref:** specify the reference of in calling a transistor model. In SPICE netlist, define a transistor follows the convention: <model_ref><trans_name> <ports> <model_name>. The reference depends on the technology and the type of library. For example, the PTM bulk model uses “M” as the reference while the PTM FinFET model uses “X” as the reference.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<nmos model_name=”string” chan_length=”float” min_width=”float”/>
|
||||
<pmos model_name=”string” chan_length=”float” min_width=”float”/>
|
||||
|
||||
* **model_name:** specify the name of the p/n type transistor, which can be found in the manual of the technology provider.
|
||||
|
||||
* **chan_length:** specify the channel length of p/n type transistor.
|
||||
|
||||
* **min_width:** specify the minimum width of p/n type transistor. This parameter will be used in building inverter, buffer, etc. as a base number for transistor sizing.
|
||||
|
||||
For OpenFPGA using VPR8
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Technology library aims to describe transistor-level parameters to be applied to the physical design of FPGAs. In addition to transistor models, technology library also supports the definition of process variations on any transistor models.
|
||||
General organization is as follows.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue