update docs
This commit is contained in:
唐希凡
parent
44e63ec98b
commit
0bfbc9b0aa
|
|
@ -1,6 +1,9 @@
|
|||
# editor backup files
|
||||
*~
|
||||
|
||||
# temp files
|
||||
.DS_Store
|
||||
|
||||
# log files
|
||||
**/logs
|
||||
*.log
|
||||
|
|
|
|||
|
|
@ -6,289 +6,354 @@ The physical modules are defined in XML syntax, similar to the original VPR FPGA
|
|||
|
||||
For each module that appears in the FPGA architecture, a spice model should be defined. In the definition of a spice model, user can specify if the SPICE netlists of the module is either auto-generated or user-defined.
|
||||
|
||||
.. note:: Define spice_models
|
||||
- <module_spice_models>
|
||||
Define spice_models
|
||||
|
||||
- <spice_model type="string" name="string" prefix="string" is_default="int" netlist="string">
|
||||
.. code-block:: xml
|
||||
|
||||
- <transistor-level circuit design features>
|
||||
<module_spice_models>
|
||||
<spice_model type="string" name="string" prefix="string" is_default="int" netlist="string">
|
||||
<transistor-level circuit design features>
|
||||
</spice_model>
|
||||
</module_spice_models>
|
||||
|
||||
- </spice_model>
|
||||
* module_spice_models: the father node for all the spice models. All the spice models should be defined under this XML node.
|
||||
|
||||
- </module_spice_models>
|
||||
* spice_model: the child node defining transistor-level modeling parameters.
|
||||
|
||||
- module_spice_models: the father node for all the spice models. All the spice models should be defined under this XML node.
|
||||
* type: can be [ inv_buf | pass_gate | mux | wire | chan_wire | sram | lut | ff | sff | hard_logic | iopad ]. Specify the type of this spice model. The provided types cover all the modules in FPGAs. For the spice models in the type of mux/wire/chan_wire/lut, FPGA-SPICE can auto-generate SPICE netlists. For the rest, FPGA-SPICE requires a user-defined SPICE netlists.
|
||||
|
||||
- spice_model: the child node defining transistor-level modeling parameters.
|
||||
* name: define the name of this spice model. The name should be unique and will be used in create the sub-circuit of the spice model in SPICE netlists. Note that for a customized SPICE netlist, the name defined here should be the name of the top-level sub-circuit in the customized SPICE netlist. FPGA-SPICE will check if the given name is conflicted with any reserved words.
|
||||
|
||||
- type: can be [ inv_buf | pass_gate | mux | wire | chan_wire | sram | lut | ff | sff | hard_logic | iopad ]. Specify the type of this spice model. The provided types cover all the modules in FPGAs. For the spice models in the type of mux/wire/chan_wire/lut, FPGA-SPICE can auto-generate SPICE netlists. For the rest, FPGA-SPICE requires a user-defined SPICE netlists.
|
||||
* prefix: specify the name of the spice_model to shown in the auto-generated SPICE netlists. The prefix can be the same as the name defined above. And again, the prefix should be unique.
|
||||
|
||||
- name: define the name of this spice model. The name should be unique and will be used in create the sub-circuit of the spice model in SPICE netlists.
|
||||
* is_default: can be [1|0], corresponding to [true|false] respectively. Specify this spice model is the default one for some modules, such as multiplexers. If a module is not linked to any spice model by users, FPGA-SPICE will find the default spice model defined in the same type and link. For a spice model type, only one spice model can be set as default.
|
||||
|
||||
- Note that for a customized SPICE netlist, the name defined here should be the name of the top-level sub-circuit in the customized SPICE netlist.
|
||||
* spice_netlist: specify the path and file name of a customized SPICE netlist. For some modules such as SRAMs, FFs, inpad and outpads, FPGA-SPICE does not support auto-generation of the transistor-level sub-circuits because their circuit design are 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-SPICE, user can also define a custom netlist. Multiplexers can not be user-defined.
|
||||
|
||||
- FPGA-SPICE will check if the given name is conflicted with any reserved words.
|
||||
* verilog_netlist: specify the path and file name of a customized Verilog netlist. For some modules such as SRAMs, FFs, inpad and outpads, FPGA-SPICE does not support auto-generation of the transistor-level sub-circuits because their circuit design are 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-SPICE, user can also define a custom netlist. Multiplexers can not be user-defined.
|
||||
|
||||
- prefix: specify the name of the spice_model to shown in the auto-generated SPICE netlists. The prefix can be the same as the name defined above. And again, the prefix should be unique.
|
||||
.. note:: If netlist is not specified, FPGA-SPICE auto-generates the SPICE netlists for multiplexers, wires and LUTs.
|
||||
|
||||
- is_default: can be [1|0], corresponding to [true|false] respectively. Specify this spice model is the default one for some modules, such as multiplexers. If a module is not linked to any spice model by users, FPGA-SPICE will find the default spice model defined in the same type and link. For a spice model type, only one spice model can be set as default.
|
||||
.. note:: The user-defined netlists, such as LUTs, the decoding methodology should comply with the auto-generated LUTs (See Section 4.5)
|
||||
|
||||
- netlist: specify the path and file name of a customized SPICE netlist. For some modules such as SRAMs, FFs, inpad and outpads, FPGA-SPICE does not support auto-generation of the transistor-level sub-circuits because their circuit design are 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-SPICE, user can also define a custom netlist. Multiplexers can not be user-defined.
|
||||
|
||||
- If netlist is not specified, FPGA-SPICE auto-generates the SPICE netlists for multiplexers, wires and LUTs.
|
||||
|
||||
- Note that if the user-defined netlists, such as LUTs, the decoding methodology should comply with the auto-generated LUTs (See Section 4.5)
|
||||
|
||||
Under the XML node spice_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 spice models types.
|
||||
.. note:: Under the XML node spice_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 spice models types.
|
||||
|
||||
|
||||
<spice_model type="string" name="string" prefix="string" is_default="int" netlist="string">
|
||||
<design_technology type="string"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<pass_gate_logic type="string" spice_model_name="string"/>
|
||||
<port type="string" prefix="string" size="int" default_val="int" spice_model_name="string" mode_select="boolean" is_global="boolean" is_set="boolean" is_reset="boolean" is_config_enable="boolean"/>
|
||||
</spice_model>
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="string" name="string" prefix="string" is_default="int" netlist="string">
|
||||
<design_technology type="string"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<pass_gate_logic type="string" spice_model_name="string"/>
|
||||
<port type="string" prefix="string" size="int" default_val="int" spice_model_name="string" mode_select="boolean" is_global="boolean" is_set="boolean" is_reset="boolean" is_config_enable="boolean"/>
|
||||
</spice_model>
|
||||
|
||||
design_technology :
|
||||
type: [cmos|rram]. Specify the type of design technology of the spice_model. 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.
|
||||
|
||||
spice_model_name: Specify the name of spice model which is used to implement input/output buffer, the type of specified spice model should be inv_buf.
|
||||
port: define the port list of a spice model.
|
||||
type: can be [input|output|sram|clock]. For programmable modules, such as multip-lexers and LUTs, SRAM ports should be defined. For registers, such as FFs and memory banks, clock ports should be defined.
|
||||
* type: [cmos|rram]. Specify the type of design technology of the spice_model.
|
||||
|
||||
prefix: the name of the port. Each port will be shown as <prefix>[i], 0≤i<size in SPICE netlists.
|
||||
.. note:: Currently, the RRAM-based designs are only supported for multiplexers.
|
||||
|
||||
size: bandwidth of the port.
|
||||
* 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.
|
||||
|
||||
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.
|
||||
* spice_model_name: Specify the name of spice model which is used to implement input/output buffer, the type of specified spice model should be inv_buf.
|
||||
|
||||
spice_model_name: only valid when the type of port is sram. Specify the name of spice model which is connected to this port.
|
||||
* port: define the port list of a spice model.
|
||||
|
||||
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.)
|
||||
* type: can be [input|output|sram|clock]. For programmable modules, such as multip-lexers and LUTs, SRAM ports should be defined. For registers, such as FFs and memory banks, clock ports should be defined.
|
||||
|
||||
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.
|
||||
* prefix: the name of the port. Each port will be shown as <prefix>[i], 0≤i<size in SPICE netlists.
|
||||
|
||||
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.
|
||||
* size: bandwidth of the port.
|
||||
|
||||
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.
|
||||
* 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.
|
||||
|
||||
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.
|
||||
pass_gate_logic: defined the parameters in pass-gates, which are used in building multiplexers and LUTs.
|
||||
* spice_model_name: only valid when the type of port is sram. Specify the name of spice model which is connected to this port.
|
||||
|
||||
spice_model_name: Specify the name of spice model which is used to implement input/output buffer, the type of specified spice model should be pass_gate.
|
||||
* 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 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_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.
|
||||
|
||||
* pass_gate_logic: defined the parameters in pass-gates, which are used in building multiplexers and LUTs.
|
||||
|
||||
* spice_model_name: Specify the name of spice model which is used to implement input/output buffer, the type of specified spice model should be pass_gate.
|
||||
|
||||
Inverters and Buffers
|
||||
=====================
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="inv_buf" name="string" prefix="string" netlist="string" is_default="1"/>
|
||||
<design_technology type="cmos" topology="string" size="int" tapered="off"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
|
||||
.. note:: customized SPICE netlists are not currently supported for inverters and buffers.
|
||||
|
||||
4.1. Inverter and buffer
|
||||
<spice_model type="inv_buf" name="string" prefix="string" netlist="string" is_default="1"/>
|
||||
<design_technology type="cmos" topology="string" size="int" tapered="off"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
Note: customized SPICE netlists are not currently supported for inverters and buffers.
|
||||
design_technology:
|
||||
topology: [inverter|buffer]. Specify the type of this component, can be either an inverter or a buffer.
|
||||
|
||||
size: Specify the driving strength of inverter/buffer. For a buffer, the size is the driving strength of the inverter at the second level. We consider a two-level structure for a buffer here. The support for multi-level structure of a buffer will be introduced in the tapered options.
|
||||
* topology: [inverter|buffer]. Specify the type of this component, can be either an inverter or a buffer.
|
||||
|
||||
tapered: [on|off]. Define if the buffer is a tapered (multi-level) buffer.
|
||||
* size: Specify the driving strength of inverter/buffer. For a buffer, the size is the driving strength of the inverter at the second level. We consider a two-level structure for a buffer here. The support for multi-level structure of a buffer will be introduced in the tapered options.
|
||||
|
||||
tap_buf_level: Define the number of levels of a tapered buffer. This parameter is valid only when tapered is turned on.
|
||||
* tapered: [on|off]. Define if the buffer is a tapered (multi-level) buffer.
|
||||
|
||||
f_per_stage: Define the ratio of driving strength between the levels of a tapered buffer. This parameter is valid only when tapered is turned on. Default value is 4.
|
||||
* tap_buf_level: Define the number of levels of a tapered buffer. This parameter is valid only when tapered is turned on.
|
||||
|
||||
is_default: Specify that this model is a default choice for input and output buffers.
|
||||
* f_per_stage: Define the ratio of driving strength between the levels of a tapered buffer. This parameter is valid only when tapered is turned on. Default value is 4.
|
||||
|
||||
* is_default: Specify that this model is a default choice for input and output buffers.
|
||||
|
||||
Pass-gate Logic
|
||||
===============
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="pass_gate" name="string" prefix="string" netlist="string" is_default="1"/>
|
||||
<design_technology type="cmos" topology="string" size="int" tapered="off"/>
|
||||
<input_buffer exist="string" spice_model_name="string" />
|
||||
<output_buffer exist="string" spice_model_name="string" />
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
|
||||
.. note:: customized SPICE netlists are not currently supported for pass-gate logics.
|
||||
|
||||
4.2. Pass-gate Logic
|
||||
<spice_model type="pass_gate" name="string" prefix="string" netlist="string" is_default="1"/>
|
||||
<design_technology type="cmos" topology="string" size="int" tapered="off"/>
|
||||
<input_buffer exist="string" spice_model_name="string" />
|
||||
<output_buffer exist="string" spice_model_name="string" />
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
Note: customized SPICE netlists are not currently supported for pass-gate logics.
|
||||
design_technology:
|
||||
topology: [transmission_gate|pass_transistor]. The transmission gate consists of a NMOS transistor and a PMOS transistor. The pass transistor consists of a NMOS transistor.
|
||||
|
||||
nmos_size: the size of NMOS transistor in a transmission gate or pass_transistor, expressed in terms of the min_width defined in XML node <transistors>.
|
||||
* topology: [transmission_gate|pass_transistor]. The transmission gate consists of a NMOS transistor and a PMOS transistor. The pass transistor consists of a NMOS transistor.
|
||||
|
||||
pmos_size: the size of PMOS transistor in a transmission gate, expressed in terms of the min_width defined in XML node <transistors>.
|
||||
* nmos_size: the size of NMOS transistor in a transmission gate or pass_transistor, expressed in terms of the min_width defined in XML node <transistors>.
|
||||
|
||||
is_default: Specify that this model is a default choice for pass-gate logics.
|
||||
* pmos_size: the size of PMOS transistor in a transmission gate, expressed in terms of the min_width defined in XML node <transistors>.
|
||||
|
||||
4.3. SRAMs
|
||||
<spice_model type="sram" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<output_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_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.
|
||||
* is_default: Specify that this model is a default choice for pass-gate logics.
|
||||
|
||||
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.
|
||||
SRAMs
|
||||
=====
|
||||
|
||||
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.
|
||||
.. code-block:: xml
|
||||
|
||||
[TO BE REPHRASED]
|
||||
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.
|
||||
<spice_model type="sram" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_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 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.
|
||||
|
||||
.. 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.
|
||||
|
||||
|
||||
4.4. Multiplexers and flexible routing architectures
|
||||
<spice_model type="mux" name="string" prefix="string" is_default="int"/>
|
||||
<design_technology type="string" structure="string" num_level="int" ron="float" roff="float" prog_transistor_size="float"/>
|
||||
<input_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<output_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<pass_gate_logic type="string" nmos_size="float" pmos_size="float"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
Note: customized SPICE netlists are not currently supported for multiplexers.
|
||||
Multiplexers
|
||||
===============================================
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="mux" name="string" prefix="string" is_default="int"/>
|
||||
<design_technology type="string" structure="string" num_level="int" ron="float" roff="float" prog_transistor_size="float"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<pass_gate_logic type="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
|
||||
.. note:: customized SPICE netlists are not currently supported for 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].
|
||||
|
||||
num_level: specify the number of levels when multi-level structure is selected.
|
||||
* 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].
|
||||
|
||||
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.
|
||||
* num_level: specify the number of levels when multi-level structure is selected.
|
||||
|
||||
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.
|
||||
* 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.
|
||||
|
||||
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>.
|
||||
* 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.
|
||||
* 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>.
|
||||
|
||||
Figure 3 illustrates an example of multiplexer modelling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
* port: for a multiplexer, the three types of ports, input, output and sram should be defined.
|
||||
|
||||
Figure 3 An example of a tree-like multiplexer with transistor-level design parameters
|
||||
: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
|
||||
|
||||
An example of a tree-like multiplexer with transistor-level design parameters
|
||||
|
||||
|
||||
Look-Up Tables
|
||||
==============
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="lut" name="string" prefix="string" is_default="int" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<lut_input_buffer exist="string" spice_model_name="string"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<pass_gate_logic type="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
|
||||
|
||||
4.5. LUTs
|
||||
<spice_model type="lut" name="string" prefix="string" is_default="int" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<lut_input_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<input_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<output_buffer exist="string" type="string" size="int" tapered="string" tap_buf_level="int" f_per_stage="float"/>
|
||||
<pass_gate_logic type="string" nmos_size="float" pmos_size="float"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
Note:
|
||||
The SPICE netlists of LUT can be auto-generated or customized.
|
||||
The auto-generated LUTs are based on a tree-like multiplexer, whose gates of the transistors are used as the inputs of LUTs and the drains/sources of the transistors are used for configurable memories (SRAMs).
|
||||
The LUT provided in customized SPICE netlist should have the same decoding methodology as the traditional LUT.
|
||||
.. note:: The SPICE netlists of LUT can be auto-generated or customized.
|
||||
The auto-generated LUTs are based on a tree-like multiplexer, whose gates of the transistors are used as the inputs of LUTs and the drains/sources of the transistors are used for configurable memories (SRAMs).
|
||||
The LUT provided in customized SPICE netlist should have the same decoding methodology as the traditional LUT.
|
||||
|
||||
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.
|
||||
|
||||
pass_gate_logic: Specify the pass-gates of the internal multiplexer, the same as the multiplexers.
|
||||
* input_buffer: Specify the buffer/inverter that connects the SRAM outputs to the inputs of multiplexer.
|
||||
|
||||
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.
|
||||
* pass_gate_logic: Specify the pass-gates of the internal multiplexer, the same as the multiplexers.
|
||||
|
||||
Figure 4 illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
* 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.
|
||||
|
||||
Figure 4 An example of a LUT with transistor-level design parameters.
|
||||
:numref:`fig_lut` illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
|
||||
|
||||
.. _fig_lut:
|
||||
|
||||
4.6. FFs
|
||||
<spice_model type="ff" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="clock" prefix="string" size="int"/>
|
||||
</spice_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.
|
||||
.. figure:: ./figures/lut.png
|
||||
:scale: 100%
|
||||
:alt: map to buried treasure
|
||||
|
||||
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.
|
||||
An example of a LUT with transistor-level design parameters.
|
||||
|
||||
FPGA-SPICE currently support only one clock domain in the FPGA. Therefore there should be only one clock port to be defined and the size of the clock port should be 1.
|
||||
Flip-Flops
|
||||
==========
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="ff" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="clock" prefix="string" size="int"/>
|
||||
</spice_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.
|
||||
|
||||
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.
|
||||
|
||||
FPGA-SPICE currently support only one clock domain in the FPGA. Therefore there should be only one clock port to be defined and the size of the clock port should be 1.
|
||||
|
||||
Instructions of defining design parameters:
|
||||
port: three types of ports (input, output and clock) 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.
|
||||
|
||||
4.7. Hard Logics
|
||||
* port: three types of ports (input, output and clock) 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.
|
||||
|
||||
<spice_model type="hardlogic" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
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.
|
||||
Hard Logics
|
||||
===========
|
||||
|
||||
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.
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="hardlogic" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
</spice_model>
|
||||
|
||||
.. 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
4.8. Wire Segments
|
||||
* 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.
|
||||
|
||||
<spice_model type="string" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<wire_param model_type="string" res_val="float" cap_val="float" level="int"/>
|
||||
</spice_model>
|
||||
Note: FPGA-SPICE can auto-generate the SPICE model for wires while also allows users to provide their customized SPICE netlists.
|
||||
.. code-block:: xml
|
||||
|
||||
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.
|
||||
<spice_model type="string" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<wire_param model_type="string" res_val="float" cap_val="float" level="int"/>
|
||||
</spice_model>
|
||||
|
||||
.. 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.
|
||||
|
||||
Instructions of defining design parameters:
|
||||
spice_model:
|
||||
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.
|
||||
* 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.
|
||||
|
||||
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.
|
||||
* 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.
|
||||
|
||||
Figure 5 depicts the modeling for a length-2 channel wire.
|
||||
.. wire_param:
|
||||
|
||||
Figure 5. An example of a length-2 channel wire modeling
|
||||
* 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.
|
||||
|
||||
:numref:`fig_wire` depicts the modeling for a length-2 channel wire.
|
||||
|
||||
.. _fig_wire:
|
||||
|
||||
4.9. I/O pads
|
||||
.. figure:: ./figures/wire.png
|
||||
:scale: 100%
|
||||
:alt: map to buried treasure
|
||||
|
||||
<spice_model type="iopads" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int" mode_select="true|false" spice_model_name="string" default_val="int"/>
|
||||
</spice_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.
|
||||
An example of a length-2 channel wire modeling
|
||||
|
||||
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.
|
||||
I/O pads
|
||||
========
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<spice_model type="iopads" name="string" prefix="string" netlist="string"/>
|
||||
<design_technology type="cmos"/>
|
||||
<input_buffer exist="string" spice_model_name="string"/>
|
||||
<output_buffer exist="string" spice_model_name="string"/>
|
||||
<port type="input" prefix="string" size="int"/>
|
||||
<port type="output" prefix="string" size="int"/>
|
||||
<port type="sram" prefix="string" size="int" mode_select="true|false" spice_model_name="string" default_val="int"/>
|
||||
</spice_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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 124 KiB |
|
Before Width: | Height: | Size: 116 KiB After Width: | Height: | Size: 116 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
|
|
@ -1,6 +1,7 @@
|
|||
General Hierarchy
|
||||
=================
|
||||
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>, a number of child node are created for describing SPICE simulation settings, technology library and transistor-level modeling of circuit modules.
|
||||
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>, a number of child node are 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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,54 +2,113 @@ Link circuit modules
|
|||
====================
|
||||
Each defined SPICE model should be linked to a FPGA module defined in the original part of architecture descriptions. It helps FPGA-SPICE creating the SPICE netlists for logic/routing blocks. Since the original part lacks such support, we create a few XML properties to link to SPICE models.
|
||||
|
||||
5.1. SRAM
|
||||
SRAM
|
||||
====
|
||||
|
||||
To link the defined SPICE 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 a SRAM and the name of SPICE model to be linked. And example is shown as follows:
|
||||
<sram area=”int” spice_model_name=”string”>
|
||||
area is expressed in terms of the number of minimum width transistors. The SRAM area defined in this line is used in the area estimation of global routing multiplexers. spice_model_name should match the name of SPICE model that have been defined under XML node module_spice_model. The type of the linked SPICE model should be sram.
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<sram area=”int” spice_model_name=”string”>
|
||||
|
||||
<sram>
|
||||
<spice organization="string" spice_model_name="scff"/>
|
||||
<verilog organization="string" spice_model_name="scff"/>
|
||||
</sram>
|
||||
|
||||
* area is expressed in terms of the number of minimum width transistors. The SRAM area defined in this line is used in the area estimation of global routing multiplexers. spice_model_name should match the name of SPICE model that have been defined under XML node module_spice_model. The type of the linked SPICE model should be sram.
|
||||
|
||||
* organization: the type of configuration circuits. available options: [scan-chain|memory_bank|standalone]. :numref:`fig_sram` illustrates an exmample where a memory organiation using memory decoders and 6-transistor SRAMs.
|
||||
|
||||
.. _fig_sram:
|
||||
|
||||
.. figure:: figures/sram.png
|
||||
:scale: 100%
|
||||
:alt: map to buried treasure
|
||||
|
||||
Example of a memory organization using memory decoders
|
||||
|
||||
.. note:: Currently SPICE only supports standalone memory organization.
|
||||
|
||||
.. note:: Currently RRAM-based FPGA only supports memory-bank organization for Verilog Generator.
|
||||
|
||||
Here is an example.
|
||||
<sram area=”4” spice_model_name=”sram6T”>
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<sram area=”4” spice_model_name=”sram6T”>
|
||||
|
||||
|
||||
5.2. Switch Blocks
|
||||
Switch Blocks
|
||||
=============
|
||||
|
||||
Original VPR architecture description contains a XML node called switchlist under which all the multiplexers of switch blocks are described.
|
||||
To link a defined SPICE model to a multiplexer in the switch blocks, a new XML property spice_model_name should added to the descriptions.
|
||||
|
||||
Here is an example:
|
||||
|
||||
<switchlist>
|
||||
<switch type=”mux” name=”string” R=”float” Cin=”float” Cout=”float” Tdel=”float” mux_trans_size=”float” buf_size=”float” spice_model_name=”string”/>
|
||||
</switchlist>
|
||||
spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models.
|
||||
.. code-block:: xml
|
||||
|
||||
<switchlist>
|
||||
<switch type=”mux” name=”string” R=”float” Cin=”float” Cout=”float” Tdel=”float” mux_trans_size=”float” buf_size=”float” spice_model_name=”string”/>
|
||||
</switchlist>
|
||||
|
||||
* spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models.
|
||||
|
||||
|
||||
5.3. Connection Boxes
|
||||
Connection Boxes
|
||||
================
|
||||
|
||||
To link the defined SPICE model of multiplexer to the Connection Boxes, a spice_model_name should be added to the definition of Connection Boxes switches. However, the original architecture descriptions do not offer a switch description for connection boxes as they do for the switch blocks.
|
||||
Therefore, FPGA-SPICE requires a new XML node called cblock under the root XML node architecture, where a switch for connection boxes can be defined.
|
||||
|
||||
Here is the example:
|
||||
<cblock>
|
||||
<switch type=”mux” name=”string” R=”float” Cin=”float” Cout=”float” Tdel=”float” mux_trans_size=”float” buf_size=”float” spice_model_name=”string”/>
|
||||
</cblock>
|
||||
spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models.
|
||||
|
||||
5.4. Channel Wire Segments
|
||||
.. code-block:: xml
|
||||
|
||||
<cblock>
|
||||
<switch type=”mux” name=”string” R=”float” Cin=”float” Cout=”float” Tdel=”float” mux_trans_size=”float” buf_size=”float” spice_model_name=”string”/>
|
||||
</cblock>
|
||||
|
||||
* spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models.
|
||||
|
||||
Channel Wire Segments
|
||||
=====================
|
||||
|
||||
Simliar to the SB and CB, the channel wire segments in the original architecture descriptions can be adapted to provide a link to the defined SPICE model.
|
||||
<segmentlist>
|
||||
<segment freq=”float” length=”int” type=”string” Rmetal=”float” Cmetal=”float” spice_model_name=”string”/>
|
||||
</segmentlist>
|
||||
spice_model_name: should match a SPICE model whose type is chan_wire defined under module_spice_models.
|
||||
|
||||
5.5. Modules inside logic blocks (pb_type)
|
||||
.. code-block:: xml
|
||||
|
||||
<segmentlist>
|
||||
<segment freq=”float” length=”int” type=”string” Rmetal=”float” Cmetal=”float” spice_model_name=”string”/>
|
||||
</segmentlist>
|
||||
|
||||
* spice_model_name: should match a SPICE model whose type is chan_wire defined under module_spice_models.
|
||||
|
||||
Primitive Blocks inside Configurable Logic Blocks
|
||||
=================================================
|
||||
|
||||
The architecture description employs a hierarchy of pb_types to depicting the sub modules and complex interconnections inside logic blocks. Each leaf node and interconnection in pb_type hierarchy should be linked to a SPICE model.
|
||||
|
||||
<pb_type name=”string” blif_model=”string” spice_model_name=”string” idle_mode_name=”string”>
|
||||
</pb_type>
|
||||
<interconnect>
|
||||
<direct name=”string” input=”string” output=”string” spice_model_name=”string”/>
|
||||
<complete name=”string” input=”string” output=”string” spice_model_name=”string”/>
|
||||
<mux name=”string” input=”string” output=”string” spice_model_name=”string”/>
|
||||
</interconnect>
|
||||
spice_model_name: should match a SPICE model defined under module_spice_models. For the interconnection type direct, the type of the linked SPICE model should be wire. For mux, the type of the linked SPICE model should be mux. For complete, the type of the linked SPICE model can be either mux or wire, depending on the case.
|
||||
.. code-block:: xml
|
||||
|
||||
idle_mode_name: tell the name of the mode that the pb_type is configured to be by default. This is critical in building SPICE netlists for unused logic blocks.
|
||||
<pb_type name="clb" idle_mode_name="ble" physical_mode_name="ble">
|
||||
<pb_type name="ble">
|
||||
<pb_type name="lut" spice_model_name="lut6">
|
||||
<pb_type name="ff" spice_model_name="dff">
|
||||
<interconnect>
|
||||
<mux input="lut.out ff.Q" output="ble.out" spice_model_name="mux_1level">
|
||||
</interconnect>
|
||||
</pb_type>
|
||||
<interconnect>
|
||||
<mux input="ble.out clb.in" output="ble.in" spice_model_name="mux_2level">
|
||||
</interconnect>
|
||||
</pb_type>
|
||||
|
||||
* spice_model_name: should match a SPICE model defined under module_spice_models. For the interconnection type direct, the type of the linked SPICE model should be wire. For mux, the type of the linked SPICE model should be mux. For complete, the type of the linked SPICE model can be either mux or wire, depending on the case.
|
||||
|
||||
* idle_mode_name: tell the name of the mode that the pb_type is configured to be by default. This is critical in building SPICE netlists for unused logic blocks.
|
||||
|
||||
* physical_mode_name: tell the name of the mode that describes the physical implementation of the block. This is critical in modeling actual circuit designs and architecture of a FPGA.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,101 +3,126 @@ Parameters for SPICE simulation settings
|
|||
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.
|
||||
|
||||
.. note:: The XML node <options>
|
||||
- <options sim_temp=”int” post=”string”captab=”string” fast=”string” />
|
||||
* The XML node <options>
|
||||
|
||||
- These properties define the options that will be printed in the top SPICE netlists.
|
||||
.. code-block:: xml
|
||||
|
||||
- sim_temp: specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as .temp <int>.
|
||||
<options sim_temp=”int” post=”string”captab=”string” fast=”string”/>
|
||||
|
||||
- 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 that when the SPICE netlists are large or a long simulation time period is defined, the post option is recommended to be off. If not, huge disk space will be occupied by the waveform files.
|
||||
These properties define the options that will be printed in the top SPICE netlists.
|
||||
|
||||
- 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.
|
||||
* sim_temp: specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as .temp <int>.
|
||||
|
||||
.. note:: The XML node <stimulate>
|
||||
- <stimulate>
|
||||
* 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.
|
||||
|
||||
- <clock op_freq=”auto|float” sim_slack=”float” prog_freq=”float”>
|
||||
.. note:: when the SPICE netlists are large or a long simulation time period is defined, the post option is recommended to be off. If not, huge disk space will be occupied by the waveform files.
|
||||
|
||||
- <rise slew_time=”float” slew_type=”string”/>
|
||||
* 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.
|
||||
|
||||
- <fall slew_time=”float” slew_type=”string”/>
|
||||
* The XML node <stimulate>
|
||||
|
||||
- </clock>
|
||||
.. code-block:: xml
|
||||
|
||||
- </stimulate>
|
||||
<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.
|
||||
Define stimulates for the clock signal.
|
||||
|
||||
- op_freq: either auto or a float number (unit:[Hz]) Specify the operation clock frequency that are 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 disgarded.
|
||||
* op_freq: either auto or a float number (unit:[Hz]) Specify the operation clock frequency that are 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 disgarded.
|
||||
|
||||
- sim_slack: add a 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.
|
||||
* sim_slack: add a 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 are used in SPICE simulations. This frequency is used in testbenches for programming phase simulation.
|
||||
* prog_freq: Specify the programming clock frequency that are 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 time 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 time period of the clock.
|
||||
* 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].
|
||||
|
||||
- Figure 2 depicts the definition of the slew and delays of signals and the parameters that can be supported by FPGA-SPICE.
|
||||
* 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 time 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 time period of the clock.
|
||||
|
||||
- <stimulate>
|
||||
:numref:`fig_meas_edge` depicts the definition of the slew and delays of signals and the parameters that can be supported by FPGA-SPICE.
|
||||
|
||||
- <input>
|
||||
.. code-block:: xml
|
||||
|
||||
- <rise slew_time=”float” slew_type=”string”/>
|
||||
<stimulate>
|
||||
<input>
|
||||
<rise slew_time=”float” slew_type=”string”/>
|
||||
<fall slew_time=”float” slew_type=”string”/>
|
||||
</input>
|
||||
</stimulate>
|
||||
|
||||
- <fall slew_time=”float” slew_type=”string”/>
|
||||
Define the slew of input signals at the rising/falling edge.
|
||||
|
||||
- </input>
|
||||
* 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].
|
||||
|
||||
- </stimulate>
|
||||
* 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 time 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 time period of the clock.
|
||||
Note that these slew settings are valid for all the input signals of the testbenches in different complexity levels.
|
||||
|
||||
- Define the slew of input signals at the rising/falling edge.
|
||||
.. _fig_meas_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 time 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 time period of the clock.
|
||||
- Note that these slew settings are valid for all the input signals of the testbenches in different complexity levels.
|
||||
.. figure:: figures/meas_edge.png
|
||||
:scale: 100%
|
||||
:alt: map to buried traesure
|
||||
|
||||
Parameter in measuring the slew and delay of signals
|
||||
|
||||
.. note:: The XML node <measure>
|
||||
- <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 time period, for example, 100.
|
||||
-
|
||||
- accuracy: specify the transient step in SPICE simulation. Typically, the smaller the step is, the higher accuracy 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.
|
||||
-
|
||||
- Users can define the parameters in measuring the slew of signals, under a child node <slew> of the node <measure>.
|
||||
- <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.
|
||||
-
|
||||
- <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.
|
||||
-
|
||||
-
|
||||
- Users can define the parameters related to measurements of delays between signals, under a child node <delay> of the node <measure>.
|
||||
- <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.
|
||||
-
|
||||
- <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 Figure 2.
|
||||
-
|
||||
- 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 Figure 2.
|
||||
* 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 time period, for example, 100.
|
||||
|
||||
* accuracy: specify the transient step in SPICE simulation. Typically, the smaller the step is, the higher accuracy 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`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,28 +1,34 @@
|
|||
Technology library Declaration
|
||||
==============================
|
||||
.. note:: <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, a number of transistor types are available and the type of transistor should be declared in the property transistor_type.
|
||||
.. code-block:: xml
|
||||
|
||||
- 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.
|
||||
<tech_lib lib_type=”string” transistor_type=”string” lib_path=”string” nominal_vdd=”float”/>
|
||||
|
||||
- lib_path: specify the path of the library. For example: lib_path=/home/tech/45nm.pm.
|
||||
* lib_type: can be either industry or academia [industry|academia]. For the industry library, a number of transistor types are available and the type of transistor should be declared in the property transistor_type.
|
||||
|
||||
- nominal_vdd: specify the working voltage for the technology. The voltage will be used as the supply voltage in all the SPICE netlist.
|
||||
* 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.
|
||||
|
||||
.. note:: <transistors pn_ratio=”float” model_ref=”string”/>
|
||||
* lib_path: specify the path of the library. For example: lib_path=/home/tech/45nm.pm.
|
||||
|
||||
- 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.
|
||||
* 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, PTM bulk model use “M” as the reference while PTM FinFET model use “X” as the reference.
|
||||
* 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, PTM bulk model use “M” as the reference while PTM FinFET model use “X” as the reference.
|
||||
|
||||
- <nmos model_name=”string” chan_length=”float” min_width=”float”/>
|
||||
.. code-block:: xml
|
||||
|
||||
- <pmos model_name=”string” chan_length=”float” min_width=”float”/>
|
||||
<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.
|
||||
* 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.
|
||||
* 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 and etc. as a base number for transistor sizing.
|
||||
* min_width: specify the minimum width of p/n type transistor. This parameter will be used in building inverter, buffer and etc. as a base number for transistor sizing.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,6 +23,12 @@ import sphinx_rtd_theme
|
|||
#html_theme = "sphinx_rtd_theme"
|
||||
#html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
|
||||
|
||||
# Import sphinxcontrib.bibtex
|
||||
have_sphinxcontrib_bibtex = True
|
||||
try:
|
||||
import sphinxcontrib.bibtex
|
||||
except ImportError:
|
||||
have_sphinxcontrib_bibtex = False
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
|
|
@ -46,11 +52,14 @@ release = u'1.0'
|
|||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'sphinx.ext.todo',
|
||||
'sphinx.ext.mathjax',
|
||||
'sphinx.ext.graphviz',
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
#templates_path = ['ytemplates']
|
||||
templates_path = []
|
||||
templates_path = [sphinx_rtd_theme.get_html_theme_path()]
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
|
|
@ -89,6 +98,7 @@ numfig = True
|
|||
# a list of builtin themes.
|
||||
#
|
||||
#html_theme = 'alabaster'
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
|
|
@ -96,7 +106,7 @@ numfig = True
|
|||
#
|
||||
# Comment when using local build
|
||||
# Uncomment when using readthedocs build
|
||||
html_theme_options = {sphinx_rtd_theme}
|
||||
#html_theme_options = {sphinx_rtd_theme}
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
|
|
|
|||
|
|
@ -3,5 +3,19 @@
|
|||
Contact
|
||||
=======
|
||||
|
||||
General questions:
|
||||
|
||||
Prof. Pierre-Emmanuel Gaillardon
|
||||
|
||||
pierre-emmanuel.gaillardon@utah.edu
|
||||
|
||||
Technical Details about FPGA-SPICE/Verilog/Bitstream:
|
||||
|
||||
Dr. Xifan Tang
|
||||
|
||||
xifan.tang@utah.edu
|
||||
|
||||
.. Technical Details about layout auto-generation
|
||||
.. Edouard Giacomin
|
||||
.. edouard.giacomin@utah.edu
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,16 @@
|
|||
EDA flow
|
||||
========
|
||||
|
||||
As illustrated in Figure 1, 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 needs the transistor-level netlists, we extend the architecture description language to support transistor-level modeling (See details in Section V). FPGA-SPICE, embedded in VPR, outputs the SPICE netlists and testbenches according to placement and routing results, when enabled by command-line options. (See Section IV for details about command-line options.) 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 Section VII for guidelines in customize your FPGA-SPICE compatible SPICE netlists.) With the dumped SPICE netlists and testbenches, a SPICE simulator, i.e. HSPICE, can be called to conduct power analysis. FPGA-SPICE automatically generates a shell script, which brings convenience for users to run all the simulations (See Section VIII).
|
||||
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 needs the transistor-level netlists, we extend the architecture description language to support transistor-level modeling (See details in Section V). FPGA-SPICE, embedded in VPR, outputs the SPICE netlists and testbenches according to placement and routing results, when enabled by command-line options. (See Section IV for details about command-line options.) 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 Section VII for guidelines in customize your FPGA-SPICE compatible SPICE netlists.) With the dumped SPICE netlists and testbenches, a SPICE simulator, i.e. HSPICE, can be called to conduct power analysis. FPGA-SPICE automatically generates a shell script, which brings convenience for users to run all the simulations (See Section VIII).
|
||||
|
||||
.. _fig_eda_flow:
|
||||
|
||||
.. figure:: figures/eda_flow.png
|
||||
:scale: 50 %
|
||||
:scale: 50%
|
||||
:alt: map to buried treasure
|
||||
|
||||
Detailed EDA flows based on FPGA-SPICE/Verilog/Bitstream in the purpose of : (a) prototyping and area analysis (b) power analysis; and (c) functionality verificaiton.
|
||||
|
||||
|
||||
How to compile
|
||||
==============
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
Command-line Options for FPGA SPICE Generator
|
||||
=================================================
|
||||
All the command line options of FPGA-SPICE can be shown by calling the help menu of VPR. Here are all the FPGA-SPICE-related options that you can find:
|
||||
FPGA Spice Support Options:
|
||||
|
||||
FPGA Spice Support Options::
|
||||
|
||||
--fpga_spice
|
||||
--fpga_spice_dir <directory_path_output_spice_netlists>
|
||||
--fpga_print_spice_top_testbench
|
||||
|
|
@ -16,12 +18,16 @@ FPGA Spice Support Options:
|
|||
--fpga_spice_leakage_only
|
||||
--fpga_spice_parasitic_net_estimation <on|off>
|
||||
|
||||
Note that FPGA-SPICE requires the input of activity estimation results (\*.act file) from ACE2. Remember to use the option --activity_file <act_file> to read the activity file.
|
||||
To dump full-chip-level testbenches, the option –-fpga_print_spice_top_testbench should be enabled.
|
||||
To dump grid-level testbenches, the options -- fpga_print_spice_grid_testbench, -- fpga_print_spice_cb_testbench and -- fpga_print_spice_sb_testbench should be enabled.
|
||||
To dump component-level testbenches, the options –fpga_print_spice_lut_testbench, --fpga_print_spice_hardlogic_testbench, --fpga_print_spice_pb_mux_testbench, --fpga_print_spice_cb_mux_testbe-nch and --fpga_print_spice_sb_mux_testbench should be enabled.
|
||||
.. note:: FPGA-SPICE requires the input of activity estimation results (\*.act file) from ACE2.
|
||||
Remember to use the option --activity_file <act_file> to read the activity file.
|
||||
|
||||
.. csv-table:: FPGA_SPICE_CMD
|
||||
.. note:: To dump full-chip-level testbenches, the option –-fpga_print_spice_top_testbench should be enabled.
|
||||
|
||||
.. note:: To dump grid-level testbenches, the options -- fpga_print_spice_grid_testbench, -- fpga_print_spice_cb_testbench and -- fpga_print_spice_sb_testbench should be enabled.
|
||||
|
||||
.. note:: To dump component-level testbenches, the options –fpga_print_spice_lut_testbench, --fpga_print_spice_hardlogic_testbench, --fpga_print_spice_pb_mux_testbench, --fpga_print_spice_cb_mux_testbench and --fpga_print_spice_sb_mux_testbench should be enabled.
|
||||
|
||||
.. csv-table:: Commmand-line Options of FPGA-SPICE
|
||||
:header: "Command Options", "Description"
|
||||
:widths: 15, 30
|
||||
|
||||
|
|
@ -35,5 +41,7 @@ To dump component-level testbenches, the options –fpga_print_spice_lut_testben
|
|||
"-- fpga_print_spice_sb_mux_testbench", "Print the testbenches for all the multiplexers in Switch Blocks."
|
||||
"--fpga_print_spice_grid_testbench", "Print the testbenches for the logic blocks."
|
||||
"--fpga_spice_leakage_only", "FPGA-SPICE conduct power analysis on the leakage power only."
|
||||
"--fpga_spice_parasitic_net_estimation <on/off>", "Default: on. Turn on or off the parasitic net estimation technique. The parasitic net estimation technique is used to analyze the parasitic net activities which improves the accuracy of power analysis. When turned off, the errors between the full-chip-level and grid/component-level testbenches will increase."
|
||||
"--fpga_spice_parasitic_net_estimation <on/off>", "Default: on. Turn on or off the parasitic net estimation technique."
|
||||
|
||||
.. note:: The parasitic net estimation technique is used to analyze the parasitic net activities which improves the accuracy of power analysis. When turned off, the errors between the full-chip-level and grid/component-level testbenches will increase."
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ To make sure the customized SPICE netlists can be correctly included in FPGA-SPI
|
|||
|
||||
2. The ports of sub-circuit to be included should strictly follow the sequence:
|
||||
<input_ports> <output_ports> <sram_ports> <clock_ports> <vdd> <gnd>
|
||||
It is not necessary to keep the names of ports be the same with what is defined in the SPICE models. But the bandwidth of the ports should be consistent with what is defined in the SPICE models.
|
||||
It is not necessary to keep the names of ports be the same with what is defined in the SPICE models. But the bandwidth of the ports should be consistent with what is defined in the SPICE models.
|
||||
|
||||
If the customized SPICE netlists includes inverters, buffers or transmission gates, it recommended to use those auto-generated by FPGA-SPICE. It is also recommend to use the transistor sub-circuit (vpr_nmos and vpr_pmos) auto-generated by FPGA-SPICE. In the appendix, we introduce how to use these useful sub-circuits.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,11 @@
|
|||
Run SPICE simulation
|
||||
====================
|
||||
|
||||
2. Simulation results
|
||||
* Simulation results
|
||||
|
||||
The HSPICE simulator creates a LIS file (\*.lis) to store the results. In each LIS file, you can find the leakage power and dynamic power of each module, as well the total leakage power and the total dynamic power of all the modules in a SPICE netlist.
|
||||
The following is an example of simulation results of a pb_mux testbench.
|
||||
|
||||
The following is an example of simulation results of a pb_mux testbench.::
|
||||
|
||||
total_leakage_srams= -16.4425u
|
||||
|
||||
|
|
@ -19,14 +21,19 @@ The following is an example of simulation results of a pb_mux testbench.
|
|||
|
||||
total_energy_per_cycle_pb_mux= -37.5871p
|
||||
|
||||
total_energy_per_cycle_srams represents the total energy per cycle of all the SRAMs of the multiplexers in this testbench, while total_energy_per_cycle_pb_mux is the total energy per cycle of all the multiplexer structures in this testbench.
|
||||
.. note:: total_energy_per_cycle_srams represents the total energy per cycle of all the SRAMs of the multiplexers in this testbench, while total_energy_per_cycle_pb_mux is the total energy per cycle of all the multiplexer structures in this testbench.
|
||||
|
||||
Therefore, the total energy per cycle of all the multiplexers in this testbench should be the sum of total_energy_per_cycle_srams and total_energy_per_cycle_pb_mux.
|
||||
|
||||
Therefore, the total energy per cycle of all the multiplexers in this testbench should be the sum of total_energy_per_cycle_srams and total_energy_per_cycle_pb_mux.
|
||||
Similiarly, the total leakage power of all the multiplexers in this testbench should the sum of total_leakage_srams and total_leakage_power_pb_mux.
|
||||
|
||||
Similiarly, the total leakage power of all the multiplexers in this testbench should the sum of total_leakage_srams and total_leakage_power_pb_mux.
|
||||
The leakage power is measured for the first clock cycle, where FPGA-SPICE set all the voltage stimuli in constant voltage levels.
|
||||
|
||||
The total energy per cycle is measured for the rest of clock cycles (the 1st clock cycle is not included).
|
||||
|
||||
The total power can be calculated by,
|
||||
|
||||
:math:`total\_energy\_per\_cycle \cdot clock\_freq`
|
||||
|
||||
The leakage power is measured for the first clock cycle, where FPGA-SPICE set all the voltage stimuli in constant voltage levels.
|
||||
The total energy per cycle is measured for the rest of clock cycles (the 1st clock cycle is not included).
|
||||
The total power can be calculated by,
|
||||
where clock_freq is the clock frequency used in SPICE simulations.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,16 @@
|
|||
Motivation
|
||||
==========
|
||||
|
||||
The built-in timing and power analysis engines of VPR are based on analytical models [1]. 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 on 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.
|
||||
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 on 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.
|
||||
|
||||
It motivates us to develop FPGA-SPICE, an add-on for the current State-of-Art FPGA architecture exploration tools, VPR [2]. FPGA-SPICE aims at generating SPICE netlists and testbenches for the FPGA architectures supported by VPR. The SPICE netlists and testbenches are generated according to the placement and routing results of VPR. As a result, SPICE simulator can be used to perform accurate delay and power analysis. The SPICE simulation results are useful in three aspects: (1) it can provide accurate power analysis; (2) it helps improving the accuracy of built-in analytical models; and moreover (3) it creates opportunities in developing novel analytical models.
|
||||
It motivates us to develop FPGA-SPICE, an add-on for the current State-of-Art FPGA architecture exploration tools, VPR :cite:`JRose_FPGA_2012` .
|
||||
FPGA-SPICE aims at generating SPICE netlists and testbenches for the FPGA architectures supported by VPR. The SPICE netlists and testbenches are generated according to the placement and routing results of VPR. As a result, SPICE simulator can be used to perform accurate delay and power analysis. The SPICE simulation results are useful in three aspects: (1) it can provide accurate power analysis; (2) it helps improving the accuracy of built-in analytical models; and moreover (3) it creates opportunities in developing novel analytical models.
|
||||
|
||||
SPICE modeling for FPGA architectures requires a detailed transistor-level modeling for all the circuit elements within the considered FPGA architecture. However, current VPR architectural description language [3] does not offer enough transistor-level parameters to model the most common circuit modules, such as multiplexers and LUTs. Therefore, we develop an extension on the VPR architectural description language in order to model the transistor-level circuit designs.
|
||||
SPICE modeling for FPGA architectures requires a detailed transistor-level modeling for all the circuit elements within the considered FPGA architecture. However, current VPR architectural description language :cite:`JLuu_FPGA_2011` does not offer enough transistor-level parameters to model the most common circuit modules, such as multiplexers and LUTs. Therefore, we develop an extension on the VPR architectural description language in order to model the transistor-level circuit designs.
|
||||
|
||||
In this manual, we will introduce how to use FPGA-SPICE to conduct accuracy power analysis. First, we give an overview on the design flow of FPGA-SPICE-based tool suites. Then, we show the command-line options of FPGA-SPICE. Afterwards, we introduce the extension on architectural language and the transistor-level design supports. Finally, we present how to simulate the generated SPICE netlists and testbenches.
|
||||
|
||||
In the appendix, we introduce the hierarchy of the generated SPICE netlists and testbenches, to help you customize the SPICE netlists. We also attach an example of architecture XML file for your interest.
|
||||
|
||||
The technical details can be found in our ICCD’15 paper [4].
|
||||
The technical details can be found in our ICCD’15 paper :cite:`XTang_ICCD_2015`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Publications & References
|
||||
========================
|
||||
=========================
|
||||
|
||||
.. bibilography:: z_reference.bib
|
||||
:all:
|
||||
|
|
|
|||
|
|
@ -27,3 +27,82 @@ doi={10.1109/JETCAS.2018.2847600},
|
|||
ISSN={2156-3357},
|
||||
month={Sept},}
|
||||
|
||||
@book{VBetz_Book_1999,
|
||||
editor = {Betz, Vaughn and Rose, Jonathan and Marquardt, Alexander},
|
||||
title = {Architecture and CAD for Deep-Submicron FPGAs},
|
||||
year = {1999},
|
||||
isbn = {0792384601},
|
||||
publisher = {Kluwer Academic Publishers},
|
||||
address = {Norwell, MA, USA},
|
||||
}
|
||||
|
||||
@article{XTang_TCAS1_2016,
|
||||
title={{A Study on the Programming Structures for RRAM-based FPGA Architectures}},
|
||||
author={Tang, Xifan and Kim, Gain and Gaillardon, Pierre-Emmanuel and De Micheli, Giovanni},
|
||||
journal={IEEE Transactions on Circuits and Systems I: Regular Papers},
|
||||
volume={63},
|
||||
number={4},
|
||||
pages={503--516},
|
||||
year={2016},
|
||||
publisher={IEEE}
|
||||
}
|
||||
|
||||
|
||||
@ARTICLE{XTang_TCAS1_2017,
|
||||
author={X. Tang and E. Giacomin and G. De Micheli and P. E. Gaillardon},
|
||||
journal={IEEE Transactions on Circuits and Systems I: Regular Papers},
|
||||
title={{Circuit Designs of High-Performance and Low-Power RRAM-Based Multiplexers Based on 4T(ransistor)1R(RAM) Programming Structure}},
|
||||
year={2017},
|
||||
volume={64},
|
||||
number={5},
|
||||
pages={1173-1186},
|
||||
keywords={Delays;Logic gates;Multiplexing;Programming;Resistance;Routing;Transistors;Circuit design;high-performance;low-power;multiplexer;resistive memory},
|
||||
doi={10.1109/TCSI.2016.2638542},
|
||||
ISSN={1549-8328},
|
||||
month={May},}
|
||||
|
||||
@inproceedings{JLuu_FPGA_2011,
|
||||
author = {Luu, Jason and Anderson, Jason Helge and Rose, Jonathan Scott},
|
||||
title = {{Architecture Description and Packing for Logic Blocks with Hierarchy, Modes and Complex Interconnect}},
|
||||
booktitle = {Proceedings of the 19th ACM/SIGDA International Symposium on Field Programmable Gate Arrays},
|
||||
series = {FPGA '11},
|
||||
year = {2011},
|
||||
isbn = {978-1-4503-0554-9},
|
||||
location = {Monterey, CA, USA},
|
||||
pages = {227--236},
|
||||
numpages = {10},
|
||||
url = {http://doi.acm.org/10.1145/1950413.1950457},
|
||||
doi = {10.1145/1950413.1950457},
|
||||
acmid = {1950457},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
keywords = {architecture description language, clustering, complex block, configurable memory, configurable multiplier, fpga, hard logic cluster, logic block, logic cluster, packing, soft logic cluster, splitting},
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{JGoeders_FPT_2012,
|
||||
author={J. B. Goeders and S. J. E. Wilton},
|
||||
booktitle={2012 International Conference on Field-Programmable Technology},
|
||||
title={{VersaPower: Power Estimation for Diverse FPGA Architectures}},
|
||||
year={2012},
|
||||
pages={229-234},
|
||||
keywords={CMOS integrated circuits;SPICE;computer architecture;field programmable gate arrays;logic CAD;CMOS technology;HDL;SPICE;VPR;VersaPower;Versatile Place and Route 6.0;academic FPGA CAD tool;complex logic block;diverse FPGA architecture;field programmable gate array;fracturable look-up table;power consumption;power estimation;size 130 nm;size 22 nm;size 45 nm;Capacitance;Field programmable gate arrays;Multiplexing;Solid modeling;Table lookup;Transistors;Wires},
|
||||
doi={10.1109/FPT.2012.6412139},
|
||||
month={Dec},}
|
||||
|
||||
@inproceedings{JRose_FPGA_2012,
|
||||
author = {Rose, Jonathan and Luu, Jason and Yu, Chi Wai and Densmore, Opal and Goeders, Jeffrey and Somerville, Andrew and Kent, Kenneth B. and Jamieson, Peter and Anderson, Jason},
|
||||
title = {{The VTR Project: Architecture and CAD for FPGAs from Verilog to Routing}},
|
||||
booktitle = {Proceedings of the ACM/SIGDA International Symposium on Field Programmable Gate Arrays},
|
||||
series = {FPGA '12},
|
||||
year = {2012},
|
||||
isbn = {978-1-4503-1155-7},
|
||||
location = {Monterey, California, USA},
|
||||
pages = {77--86},
|
||||
numpages = {10},
|
||||
url = {http://doi.acm.org/10.1145/2145694.2145708},
|
||||
doi = {10.1145/2145694.2145708},
|
||||
acmid = {2145708},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
keywords = {CAD, FPGA, architecture},
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue