Update_doc_circuit_level_fig_fixed
This commit is contained in:
Aurelien Alacchi
parent
d1c01cd68b
commit
a43574e593
|
|
@ -1,7 +1,7 @@
|
|||
Define Circuit-level Modules
|
||||
============================
|
||||
|
||||
To support FPGA SPICE, Verilog and Bitstream Generator, physical modules containing gate-level and transistor-level features are required for FPGA primitive blocks.
|
||||
To support FPGA 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, user can specify if the SPICE netlist of the module is either auto-generated or user-defined.
|
||||
|
|
@ -57,41 +57,41 @@ Transistor level
|
|||
|
||||
* design_technology :
|
||||
|
||||
* type: [cmos|rram]. Specify the type of design technology of the circuit_model.
|
||||
* **type:** [cmos|rram]. Specify the type of design technology of the circuit_model.
|
||||
|
||||
.. note:: Currently, the RRAM-based designs are only supported for multiplexers.
|
||||
|
||||
* 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 SPICE netlist.
|
||||
* **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 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.
|
||||
* **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 circuit model which is used to implement transmission gate, the type of specified spice model should be pass_gate.
|
||||
* **circuit_model_name:** Specify the name of circuit model which is used to implement transmission gate, the type of specified spice 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.
|
||||
* **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. Each port will be shown as <prefix>[i], 0≤i<size in SPICE netlists.
|
||||
* **prefix:** the name of the port. Each port will be shown as <prefix>[i], 0≤i<size in SPICE netlists.
|
||||
|
||||
* size: bandwidth of the port.
|
||||
* **size:** bandwidth of the port.
|
||||
|
||||
* default_val: default logic value of a port, which is used as 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.
|
||||
* **default_val:** default logic value of a port, which is used as 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 circuit model which is connected to this port.
|
||||
* **circuit_model_name:** only valid when the type of port is sram. Specify the name of 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.)
|
||||
* **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_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 a global set voltage stimuli in testbenches.
|
||||
* **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 a 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_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 a global configuration-enable 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 a global configuration-enable voltage stimuli in testbenches.
|
||||
|
||||
Circuit model examples
|
||||
======================
|
||||
|
|
@ -132,9 +132,9 @@ Inverters and Buffers
|
|||
:scale: 100%
|
||||
:alt: classical inverter x1 symbol
|
||||
|
||||
Classical inverter x1 symbol
|
||||
Classical inverter x1 symbol.
|
||||
|
||||
The XML code to describe this inverter is:
|
||||
The XML code describing this inverter is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
|
@ -160,7 +160,9 @@ This example shows:
|
|||
:scale: 100%
|
||||
:alt: buffer symbol composed by 2 inverter, its output strength equal 2
|
||||
|
||||
The XML code to describe this buffer is:
|
||||
Buffer made by two inverter, with an output strength of 2.
|
||||
|
||||
The XML code describing this buffer is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
|
@ -186,7 +188,9 @@ This example shows:
|
|||
:scale: 100%
|
||||
:alt: tapered inverter composed by 3 inverter for an output strength = 16
|
||||
|
||||
The XML code to describe this inverter is:
|
||||
Inverter with high output strength made by 3 stage of inverter.
|
||||
|
||||
The XML code describing this inverter is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
|
@ -228,6 +232,64 @@ Pass-gate Logic
|
|||
|
||||
* **pmos_size:** the size of PMOS transistor in a transmission gate, expressed in terms of the min_width defined in XML node <transistors>.
|
||||
|
||||
**Transmission-gate example**
|
||||
|
||||
:numref:`fig_passgate` is the pass-gate symbol depicted in this example.
|
||||
|
||||
.. _fig_passgate:
|
||||
|
||||
.. figure:: ./figures/pass-gate.png
|
||||
:scale: 60%
|
||||
:alt: pmos and nmos transistortors forming a pass-gate
|
||||
|
||||
Pass-gate made by pmos ans nmos association.
|
||||
|
||||
The XML code describing this pass-gate is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model_type="pass_gate" name="tgate" prefix="tgate">
|
||||
<design_technology type="cmos" topology="transmission_gate"/>
|
||||
<port_type="input" prefix="in" size="1"/>
|
||||
<port_type="input" prefix="sram" size="1"/>
|
||||
<port_type="input" prefix="sramb" size="1"/>
|
||||
<port_type="output" prefix="out" size="1"/>
|
||||
</circuit_model>
|
||||
|
||||
This example shows:
|
||||
* Topology is **transmission_gate**, which means the component need entries for each transistor gate (pmos and nmos)
|
||||
* 3 inputs considered, 1 for signal and 2 to control the transistors gates
|
||||
* No input or output buffer used, these parameters can be uninitialized
|
||||
|
||||
**Pass-transistor example**
|
||||
|
||||
:numref:`fig_passtran` is the pass-gate symbol depicted in this example.
|
||||
|
||||
.. _fig_passtran:
|
||||
|
||||
.. figure:: ./figures/pass_transistor.png
|
||||
:scale: 50%
|
||||
:alt: nmos transistortor forming a pass-gate
|
||||
|
||||
Pass-gate made by a nmos transistor.
|
||||
|
||||
The XML code describing this pass-gate is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model_type="pass_gate" name="t_pass" prefix="t_pass">
|
||||
<design_technology type="cmos" topology="pass_transistor"/>
|
||||
<port_type="input" prefix="in" size="1"/>
|
||||
<port_type="input" prefix="sram" size="1"/>
|
||||
<port_type="output" prefix="out" size="1"/>
|
||||
</circuit_model>
|
||||
|
||||
This example shows:
|
||||
* Topology is **pass_transistor**, which means the component need an entry for the transistor gate (nmos)
|
||||
* 2 inputs considered, 1 for signal and 1 to control the transistor gate
|
||||
* No input or output buffer used, these parameters can be uninitialized
|
||||
|
||||
|
||||
SRAMs
|
||||
-----
|
||||
|
||||
|
|
@ -241,7 +303,7 @@ SRAMs
|
|||
<port type="output" prefix="string" size="int"/>
|
||||
</circuit_model>
|
||||
|
||||
.. note:: The circuit designs of SRAMs are highly dependent on the technology node and well optimized by engineers. Therefore, FPGA-SPICE requires users to provide their customized SRAM SPICE netlists. A sample SPICE netlist of SRAM can be found in the directory SpiceNetlists in the released package. FPGA-SPICE assumes that all the LUTs and MUXes employ the SRAM circuit design. Therefore, currently only one SRAM type is allowed to be defined.
|
||||
.. note:: The circuit designs of SRAMs are highly dependent on the technology node and well optimized by engineers. Therefore, FPGA-SPICE requires users to provide their customized SRAM SPICE/Verilog netlists. A sample SPICE netlist of SRAM can be found in the directory SpiceNetlists in the released package. FPGA-SPICE assumes that all the LUTs and MUXes employ the SRAM circuit design. Therefore, currently only one SRAM type is allowed to be defined.
|
||||
|
||||
.. note:: The information of input and output buffer should be clearly specified according to the customized SPICE netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
|
||||
|
|
@ -267,28 +329,82 @@ Multiplexers
|
|||
|
||||
* design_technology:
|
||||
|
||||
* structure: can be [tree|multi-level|one-level]. The structure options are valid for SRAM-based multiplexers. For RRAM-based multiplexers, currently we only support the circuit design in [5].
|
||||
* **structure:** can be [tree|multi-level|one-level]. The structure options are valid for SRAM-based multiplexers. For RRAM-based multiplexers, currently we only support the circuit design in [5]. If *multi-level* the following parameter is required:
|
||||
|
||||
* num_level: specify the number of levels when multi-level structure is selected.
|
||||
* **num_level:** specify the number of levels when multi-level structure is selected, only.
|
||||
|
||||
* ron: valid only when the type of design technology is rram. Specify the on-resistance of the RRAM device used in the RRAM-based multiplexer.
|
||||
|
||||
* roff: valid only when the type of design technology is rram. Specify the off-resistance of the RRAM device used in the RRAM-based multiplexer.
|
||||
* **prog_transistor_size:** valid only when the type of design technology is rram. Specify the size of programming transistors used in the RRAM-based multiplexer, we use only n-type transistor and the size should be expressed in terms of the min_width defined in XML node <transistors>.
|
||||
|
||||
* prog_transistor_size: valid only when the type of design technology is rram. Specify the size of programming transistors used in the RRAM-based multiplexer, we use only n-type transistor and the size should be expressed in terms of the min_width defined in XML node <transistors>.
|
||||
* If type of design technology is **rram**, then the following parameters are required:
|
||||
|
||||
* **ron:** valid only when the type of design technology is rram. Specify the on-resistance of the RRAM device used in the RRAM-based multiplexer.
|
||||
|
||||
* **roff:** valid only when the type of design technology is rram. Specify the off-resistance of the RRAM device used in the RRAM-based multiplexer.
|
||||
|
||||
* port: for a multiplexer, the three types of ports, input, output and sram should be defined.
|
||||
|
||||
**Mux 1 level example**
|
||||
|
||||
:numref:`fig_mux1` illustrates an example of multiplexer modelling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
.. _fig_mux1:
|
||||
|
||||
.. figure:: ./figures/mux1lvl.png
|
||||
:scale: 60%
|
||||
:alt: Detailed one level Multiplexer
|
||||
|
||||
An example of a one level multiplexer with transistor-level design parameters
|
||||
|
||||
The code describing this Multiplexer is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit model type="mux" name="mux 1level" prefix="mux 1level">
|
||||
<design technology type="cmos" structure="one-level"/>
|
||||
<input buffer exist="on" circuit model name="inv1x"/>
|
||||
<output buffer exist="on" circuit model name="tapbuf4"/>
|
||||
<pass gate logic circuit model name="tgate"/>
|
||||
<port type="input" prefix="in" size="4"/>
|
||||
<port type="output" prefix="out" size="1"/>
|
||||
<port type="sram" prefix="sram" size="4"/>
|
||||
</circuit model>
|
||||
|
||||
**This example shows:**
|
||||
* Each circuit model composing the Multiplexer
|
||||
* The possibility to select the input or output buffers
|
||||
* The possibility to select the pass-gate inside the Mux.
|
||||
|
||||
**Mux-tree example**
|
||||
|
||||
:numref:`fig_mux` illustrates an example of multiplexer modelling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
.. _fig_mux:
|
||||
|
||||
.. figure:: ./figures/mux.png
|
||||
:scale: 100%
|
||||
:alt: map to buried treasure
|
||||
:alt: Examples of Mux-tree
|
||||
|
||||
An example of a tree-like multiplexer with transistor-level design parameters
|
||||
|
||||
If we arbitrarily fix the number of Mux entries at 4, the following code could illustrate (a):
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model_type="mux" name="mux_tree" prefix="mux_tree">
|
||||
<design_technology type="cmos" structure="tree"/>
|
||||
<input_buffer exist="on" circuit_model_name="inv1x"/>
|
||||
<output_buffer exist="on" circuit_model_name="tapdrive4"/>
|
||||
<pass_gate_logic circuit_model_name="tgate"/>
|
||||
<port_type="input" prefix="in" size="4"/>
|
||||
<port_type="output" prefix="out" size="1"/>
|
||||
<port_type="sram" prefix="sram" size="3"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows:**
|
||||
* The tree topology, 4 entries split in 2 2-to-1 Muxes then another one make the final selection.
|
||||
* The possibility to select the input or output buffers
|
||||
* The number of entries parametrized by *size* in input port-type.
|
||||
|
||||
Look-Up Tables
|
||||
--------------
|
||||
|
|
@ -312,15 +428,17 @@ Look-Up Tables
|
|||
|
||||
Additional design parameters for LUTs:
|
||||
|
||||
* lut_input_buffer : Specify the buffer for the inputs of a LUT (gates of the internal multiplexer).
|
||||
* **lut_input_buffer:** Specify the buffer for the inputs of a LUT (gates of the internal multiplexer).
|
||||
|
||||
Instructions of defining design parameters:
|
||||
|
||||
* input_buffer: Specify the buffer/inverter that connects the SRAM outputs to the inputs of multiplexer.
|
||||
* **input_buffer:** Specify the buffer/inverter that connects the SRAM outputs to the inputs of multiplexer.
|
||||
|
||||
* pass_gate_logic: Specify the pass-gates of the internal multiplexer, the same as the multiplexers.
|
||||
* **pass_gate_logic:** Specify the pass-gates of the internal multiplexer, the same as the multiplexers.
|
||||
|
||||
* port: three types of ports (input, output and sram) should be defined. If the user provides an customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
* **port:** three types of ports (input, output and sram) should be defined. If the user provides an customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
|
||||
**LUT example**
|
||||
|
||||
:numref:`fig_lut` illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
|
|
@ -328,10 +446,28 @@ Instructions of defining design parameters:
|
|||
|
||||
.. figure:: ./figures/lut.png
|
||||
:scale: 100%
|
||||
:alt: map to buried treasure
|
||||
:alt: Detailed LUT composition
|
||||
|
||||
An example of a LUT with transistor-level design parameters.
|
||||
|
||||
The code describing this LUT is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="lut" name="lut6" prefix="lut6">
|
||||
<input_buffer exist="on" circuit_model="inv1x"/>
|
||||
<output_buffer exist="on" circuit_model_name="inv1x"/>
|
||||
<lut_input_buffer exist="on" circuit_model_name="buf2"/>
|
||||
<pass_gate_logic circuit_model_name="tgate"/>
|
||||
<port_type="input" prefix="in" size="6"/>
|
||||
<port_type="output" prefix="out" size="1"/>
|
||||
<port_type="sram" prefix="sram" size="64"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows:**
|
||||
* The difference between *input_buffer* and *lut_input_buffer*.
|
||||
* How each blocks is defined
|
||||
|
||||
Flip-Flops
|
||||
----------
|
||||
|
||||
|
|
@ -346,7 +482,7 @@ Flip-Flops
|
|||
<port type="clock" prefix="string" size="int"/>
|
||||
</circuit_model>
|
||||
|
||||
.. note:: The circuit designs of flip-flops are highly dependent on the technology node and well optimized by engineers. Therefore, FPGA-SPICE requires users to provide their customized SRAM SPICE netlists. A sample SPICE netlist of FF can be found in the directory SpiceNetlists in the released package.
|
||||
.. note:: The circuit designs of flip-flops are highly dependent on the technology node and well optimized by engineers. Therefore, FPGA-SPICE requires users to provide their customized FF SPICE/Verilog netlists. A sample SPICE netlist of FF can be found in the directory SpiceNetlists in the released package.
|
||||
|
||||
The information of input and output buffer should be clearly specified according to the customized SPICE netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
|
||||
|
|
@ -354,7 +490,65 @@ Flip-Flops
|
|||
|
||||
Instructions of defining design parameters:
|
||||
|
||||
* port: three types of ports (input, output and clock) should be defined. If the user provides a customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
* **circuit_model type:** can be ff or scff. FF is typical Flip-Flop, SCFF is Scan-Chain Flip-Flop
|
||||
|
||||
* **port:** three types of ports (input, output and clock) should be defined. If the user provides a customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
|
||||
**FF example**
|
||||
|
||||
:numref:`fig_ff` illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
.. _fig_ff:
|
||||
|
||||
.. figure:: ./figures/ff.png
|
||||
:scale: 100%
|
||||
:alt: FF symbol
|
||||
|
||||
An example of classical Flip-Flop.
|
||||
|
||||
The code describing this FF is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="ff" name="dff" prefix="dff" verilog_netlist="ff.v">
|
||||
<port_type="input" prefix="D" size="1"/>
|
||||
<port_type="input" prefix="Set" size="1" is_global="true"/>
|
||||
<port_type="input" prefix="Reset" size="1" is_global="true"/>
|
||||
<port_type="output" prefix="Q" size="1"/>
|
||||
<port_type="clock" prefix="clk" size="1" is_global="true"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows:**
|
||||
* Circuit model type as ff
|
||||
* The verilog netlist file associated to this component *ff.v*
|
||||
* 3 ports, *Set*, *Reset* and *clk*, defined as global
|
||||
|
||||
**SCFF example**
|
||||
|
||||
:numref:`fig_scff` illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
.. _fig_scff:
|
||||
|
||||
.. figure:: ./figures/scff.png
|
||||
:scale: 100%
|
||||
:alt: SCFF symbol
|
||||
|
||||
An example of a Scan-Chain Flip-Flop.
|
||||
|
||||
The code describing this FF is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="scff" name="scff" prefix="scff" verilog_netlist="scff.v">
|
||||
<port_type="input" prefix="D" size="1"/>
|
||||
<port_type="output" prefix="Q" size="2"/>
|
||||
<port_type="clock" prefix="clk" size="1" is_global="true"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows:**
|
||||
* Circuit model type as scff
|
||||
* The verilog netlist file associated to this component *scff.v*
|
||||
* 1 port, *clk*, defined as global
|
||||
|
||||
Hard Logics
|
||||
-----------
|
||||
|
|
@ -369,7 +563,7 @@ Hard Logics
|
|||
<port type="output" prefix="string" size="int"/>
|
||||
</circuit_model>
|
||||
|
||||
.. note:: hard logics are defined for non-configurable resources in FPGA architectures, such as adders, multipliers and RAM blocks.
|
||||
.. note:: Hard logics are defined for non-configurable resources in FPGA architectures, such as adders, multipliers and RAM blocks.
|
||||
Their circuit designs are highly dependent on the technology node and well optimized by engineers.
|
||||
As more functional units are included in FPGA architecture, it is impossible to auto-generate these functional units [3].
|
||||
Therefore, FPGA-SPICE requires users to provide their customized SPICE netlists. A sample SPICE netlist of a 1-bit adder can be found in the directory SpiceNetlists in the released package.
|
||||
|
|
@ -378,12 +572,15 @@ Hard Logics
|
|||
|
||||
Instructions of defining design parameters:
|
||||
|
||||
* port: two types of ports (input and output) should be defined. If the user provides a user-defined SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
* **port:** two types of ports (input and output) should be defined. If the user provides a user-defined SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
|
||||
Routing Wire Segments
|
||||
---------------------
|
||||
FPGA-SPICE provides two types of SPICE models for the wire segments in FPGA architecture. One type is called wire, which targets the local wires inside the logic blocks. The wire has one input and one output, directly connecting the output of a driver and the input of the downsteam unit, respectively
|
||||
The other type is called chan_wire, especially targeting the channel wires. The channel wires have one input and two outputs, one of which is connected to the inputs of Connection Boxes while the other is connected to the inputs of Switch Boxes. Two outputs are created because from the view of layout, the inputs of Connection Boxes are typically connected to the middle point of channel wires, which has less parasitic resistances and capacitances than connected to the ending point.
|
||||
|
||||
FPGA-SPICE provides two types of SPICE models for the wire segments in FPGA architecture:
|
||||
|
||||
* One type is called **wire**, which targets the local wires inside the logic blocks. The wire has one input and one output, directly connecting the output of a driver and the input of the downstream unit, respectively
|
||||
* The other type is called **chan_wire**, especially targeting the channel wires. The channel wires have one input and two outputs, one of which is connected to the inputs of Connection Boxes while the other is connected to the inputs of Switch Boxes. Two outputs are created because from the view of layout, the inputs of Connection Boxes are typically connected to the middle point of channel wires, which has less parasitic resistances and capacitances than connected to the ending point.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
|
@ -398,20 +595,22 @@ The other type is called chan_wire, especially targeting the channel wires. The
|
|||
|
||||
.. note:: FPGA-SPICE can auto-generate the SPICE model for wires while also allows users to provide their customized SPICE netlists.
|
||||
|
||||
The information of input and output buffer should be clearly specified according to the customized SPICE netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
The information of input and output buffer should be clearly specified according to the customized netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
|
||||
Instructions of defining design parameters:
|
||||
|
||||
* type: can be [wire|chan_wire]. The SPICE model wire targets the local wire inside the logic block while the chan_wire targets the channel wires in global routing.
|
||||
* **type:** can be [wire|chan_wire]. The SPICE model wire targets the local wire inside the logic block while the chan_wire targets the channel wires in global routing.
|
||||
|
||||
* port: two types of ports (input and output) should be defined. If the user provides an customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
* **port:** two types of ports (input and output) should be defined. If the user provides an customized SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
|
||||
* wire_param:
|
||||
* **wire_param:**
|
||||
|
||||
* model_type: can be [pie|T], corresponding to the π-type and T-type RC wire models.
|
||||
* res_val: specify the total resistance of the wire
|
||||
* cap_val: specify the total capacitance of the wire.
|
||||
* level: specify the number of levels of the RC wire model.
|
||||
* **model_type:** can be [pi|T], corresponding to the π-type and T-type RC wire models.
|
||||
* **res_val:** specify the total resistance of the wire
|
||||
* **cap_val:** specify the total capacitance of the wire.
|
||||
* **level:** specify the number of levels of the RC wire model.
|
||||
|
||||
**Chan-Wire example**
|
||||
|
||||
:numref:`fig_wire` depicts the modeling for a length-2 channel wire.
|
||||
|
||||
|
|
@ -423,6 +622,21 @@ Instructions of defining design parameters:
|
|||
|
||||
An example of a length-2 channel wire modeling
|
||||
|
||||
The code describing this wire is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="chan_wire" name="segment0" prefix="chan_wire"/>
|
||||
<design_technology type="cmos"/>
|
||||
<port type="input" prefix="mux_out" size="1"/>
|
||||
<port type="output" prefix="cb_sb" size="2"/>
|
||||
<wire_param model_type="pi" res_val="103.84" cap_val="13.80e-15" level="1"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows**
|
||||
* How to use the *wire_param* for a π-type RC wire model
|
||||
* How to use this circuit_model to auto-generate the SPICE netlist
|
||||
|
||||
I/O pads
|
||||
--------
|
||||
|
||||
|
|
@ -438,14 +652,42 @@ I/O pads
|
|||
</circuit_model>
|
||||
|
||||
.. note:: The circuit designs of I/O pads are highly dependent on the technology node and well optimized by engineers.
|
||||
Therefore, FPGA-SPICE requires users to provide their customized SPICE netlists. A sample SPICE netlist of an I/O pad can be found in the directory SpiceNetlists in the released package.
|
||||
Therefore, FPGA-SPICE requires users to provide their customized SPICE/Verilog netlists. A sample SPICE netlist of an I/O pad can be found in the directory SpiceNetlists in the released package.
|
||||
|
||||
The information of input and output buffer should be clearly specified according to the customized SPICE netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
The information of input and output buffer should be clearly specified according to the customized netlist! The existence of input/output buffers will influence the decision in creating testbenches, which may leads to larger errors in power analysis.
|
||||
|
||||
Instructions of defining design parameters:
|
||||
|
||||
* port: two types of ports (input and output) should be defined. If the user provides a user-defined SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
* **port:** two types of ports (input and output) should be defined. If the user provides a user-defined SPICE netlist, the bandwidth of ports should be defined to the same as the SPICE netlist.
|
||||
|
||||
**IO-pad example**
|
||||
|
||||
:numref:`fig_iopad` depicts an IO-Pad.
|
||||
|
||||
.. _fig_iopad:
|
||||
|
||||
.. figure:: ./figures/iopad.png
|
||||
:scale: 100%
|
||||
:alt: IO-Pad symbol
|
||||
|
||||
An example of an IO-Pad
|
||||
|
||||
The code describing this IO-Pad is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<circuit_model type="iopad" name="iopad" prefix="iopad" verilog_netlist="io.v">
|
||||
<port_type="inout" prefix="pad" size="1"/>
|
||||
<port_type="sram" prefix="dir" size="1" circuit_model_name="scff"/>
|
||||
<port_type="input" prefix="data_in" size="1"/>
|
||||
<port_type="input" prefix="zin" size="1" is_global="true"/>
|
||||
<port_type="output" prefix="data out" size="1"/>
|
||||
</circuit_model>
|
||||
|
||||
**This example shows**
|
||||
|
||||
* The association of the verilog netlist file *io.v*
|
||||
* The inout pad port_type, which means as inout as output.
|
||||
* The instantiation of a SCFF as sram
|
||||
|
||||
|
||||
|
||||
6)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 558 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Loading…
Reference in New Issue