riscv
/
OpenFPGA
mirror of https://github.com/lnis-uofu/OpenFPGA.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update a draft

This commit is contained in:
Xifan Tang 2018-09-13 22:58:54 -06:00
parent 0f31d51c1a
commit fec0daa2a8
20 changed files with 639 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

297
docs/source/arch_lang/circuit_modules.rst Normal file
View File

@ -0,0 +1,297 @@
Define Circuit-level Modules
========================================================================
To support FPGA SPICE, Verilog and Bitstream Generator, physical modules containing gate-level and transistor-level features are required for FPGA primitive blocks.
The physical modules are defined in XML syntax, similar to the original VPR FPGA architecture description language.
For each module that appears in the FPGA architecture, a 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>
- <spice_model type="string" name="string" prefix="string" is_default="int" netlist="string">
- <transistor-level circuit design features>
- </spice_model>
- </module_spice_models>
- module_spice_models: the father node for all the spice models. All the spice models should be defined under this XML node.
- spice_model: the child node defining transistor-level modeling parameters.
- 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.
- 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.
- 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.
- 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.
- 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.
<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.
prefix: the name of the port. Each port will be shown as <prefix>[i], 0≤i<size in SPICE netlists.
size: bandwidth of the port.
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: only valid when the type of port is sram. Specify the name of spice model which is connected to this port.
mode_select: can be either true or false. Specify if this port controls the mode switching in a configurable logic block. Only valid when the type of this port is sram. (A configurable logic block can operate in different modes, which is controlled by SRAM bits.)
is_global: can be either true or false. Specify if this port is a global port, which will be routed globally. Note that when multiple global ports are defined with the same name, these global ports will be short-wired together.
is_set: can be either true or false. Specify if this port controls a set signal. Only valid when is_global is true. All the set ports are connected to 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.
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.
tapered: [on|off]. Define if the buffer is a tapered (multi-level) buffer.
tap_buf_level: Define the number of levels of a tapered buffer. This parameter is valid only when tapered is turned on.
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.
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>.
pmos_size: the size of PMOS transistor in a transmission gate, 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.
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.
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.
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.
[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.
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.
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.
ron: valid only when the type of design technology is rram. Specify the on-resistance of the RRAM device used in the RRAM-based multiplexer.
roff: valid only when the type of design technology is rram. Specify the off-resistance of the RRAM device used in the RRAM-based multiplexer.
prog_transistor_size: valid only when the type of design technology is rram. Specify the size of programming transistors used in the RRAM-based multiplexer, we use only n-type transistor and the size should be expressed in terms of the min_width defined in XML node <transistors>.
port: for a multiplexer, the three types of ports, input, output and sram should be defined.
Figure 3 illustrates an example of multiplexer modelling, which consists of input/output buffers and a transmission-gate-based tree structure.
Figure 3 An example of a tree-like multiplexer with transistor-level design parameters
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.
Additional design parameters for LUTs:
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.
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 illustrates an example of LUT modeling, which consists of input/output buffers and a transmission-gate-based tree structure.
Figure 4 An example of a LUT with transistor-level design parameters.
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.
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
<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
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.
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.
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.
Figure 5 depicts the modeling for a length-2 channel wire.
Figure 5. An example of a length-2 channel wire modeling
4.9. I/O pads
<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.

4
docs/source/arch_lang/define_phy_modules.rst
View File

@ -1,4 +0,0 @@
Define a physical module for FPGA SPICE, Verilog and Bitstream Generator
========================================================================

7
docs/source/arch_lang/generality.rst Normal file
View File

@ -0,0 +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.
In the following sub-sections, we will introduce the structures of these XML nodes and the parameters provided.

10
docs/source/arch_lang/index.rst
View File

@ -3,10 +3,16 @@
.. toctree::
:maxdepth: 2
generality
spice_sim_setting
tech_lib
define_phy_modules
circuit_modules
link_phy_modules
link_circuit_modules
multimode_support

55
docs/source/arch_lang/link_circuit_modules.rst Normal file
View File

@ -0,0 +1,55 @@
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
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.
Here is an example.
<sram area=”4” spice_model_name=”sram6T”>
5.2. 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.
5.3. 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
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)
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.
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.

2
docs/source/arch_lang/link_phy_modules.rst
View File

@ -1,2 +0,0 @@
Link defined physical modules to the original VPR architecture description
==========================================================================

103
docs/source/arch_lang/spice_sim_setting.rst Normal file
View File

@ -0,0 +1,103 @@
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” />
- These properties define the options that will be printed in the top SPICE netlists.
- sim_temp: specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as .temp <int>.
- post: [on|off]. Specify if the simulation waveforms should be printed out after SPICE simulations. In all the SPICE netlists, it will show as .option POST when turned on.
- Note 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.
- 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.
.. note:: The XML node <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.
- 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.
- 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.
- Figure 2 depicts the definition of the slew and delays of signals and the parameters that can be supported by FPGA-SPICE.
- <stimulate>
- <input>
- <rise slew_time=”float” slew_type=”string”/>
- <fall slew_time=”float” slew_type=”string”/>
- </input>
- </stimulate>
- Define the slew of input signals at the rising/falling edge.
- slew_type&slew_time: define the slew of all the input signals at the rising/falling edge. Property slew_type can be either absolute or fractional [abs|frac].
- The type of absolute implies that the slew time is the absolute value. For example, slew_time=20e-12, slew_type=abs means that the slew of a clock signal is 20ps.
- The type of fractional means that the slew time is related to the 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.
.. 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.

28
docs/source/arch_lang/tech_lib.rst Normal file
View File

@ -0,0 +1,28 @@
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.
- transistor_type: This XML property specify the transistors to be used in the industry library. For example, the type of transistors can be “TT”, “FF” etc.
- lib_path: specify the path of the library. For example: lib_path=/home/tech/45nm.pm.
- nominal_vdd: specify the working voltage for the technology. The voltage will be used as the supply voltage in all the SPICE netlist.
.. note:: <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.
- <nmos model_name=”string” chan_length=”float” min_width=”float”/>
- <pmos model_name=”string” chan_length=”float” min_width=”float”/>
- model_name: specify the name of the p/n type transistor, which can be found in the manual of the technology provider.
- chan_length: specify the channel length of p/n type transistor.
- min_width: specify the minimum width of p/n type transistor. This parameter will be used in building inverter, buffer and etc. as a base number for transistor sizing.

14
docs/source/eda_flow.rst Normal file
View File

@ -0,0 +1,14 @@
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).
.. figure:: figures/eda_flow.png
:scale: 50 %
:alt: map to buried treasure
How to compile
==============
Running the Makefile in the released package can compile all the source codes.
The released package includes a version of VPR with FPGA-SPICE support, ABC with black box support and Activity Estimator.

BIN
docs/source/figures/eda_flow.pdf Normal file
View File

Binary file not shown.

BIN
docs/source/figures/eda_flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 268 KiB

BIN
docs/source/figures/meas_edge.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 116 KiB

39
docs/source/fpga_spice/command_line_usage.rst
View File

@ -1,2 +1,39 @@
Command-line Options for FPGA Bitstream Generator
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
--fpga_spice_dir <directory_path_output_spice_netlists>
--fpga_print_spice_top_testbench
--fpga_print_spice_lut_testbench
--fpga_print_spice_hardlogic_testbench
--fpga_print_spice_pb_mux_testbench
--fpga_print_spice_cb_mux_testbench
--fpga_print_spice_sb_mux_testbench
--fpga_print_spice_grid_testbench
--fpga_print_spice_cb_testbench
--fpga_print_spice_sb_testbench
--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.
.. csv-table:: FPGA_SPICE_CMD
:header: "Command Options", "Description"
:widths: 15, 30
"--fpga_spice", "Turn on the FPGA-SPICE."
"--fpga_spice_dir <dir_path>", "Specify the directory that all the SPICE netlists will be outputted to. <dir_path> is the destination directory."
"--fpga_print_spice_top_testbench", "Print the full-chip-level testbench for the FPGA."
"--fpga_print_spice_lut_testbench", "Print the testbenches for all the LUTs."
"--fpga_print_spice_dff_testbench", "Print the testbenches for all the FFs."
"--fpga_print_spice_pb_mux_testbench", "Print the testbenches for all the multiplexers in the logic blocks."
"--fpga_print_spice_cb_mux_testbench", "Print the testbenches for all the multiplexers in Connection Boxes."
"-- 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."

12
docs/source/fpga_spice/customize_subckt.rst Normal file
View File

@ -0,0 +1,12 @@
Create Customized SPICE Modules
===============================
To make sure the customized SPICE netlists can be correctly included in FPGA-SPICE, the following rules should be fully respected:
1. The customized SPICE netlists could contain multiple sub-circuits but the names of these sub-circuits should not be conflicted with any reserved words.. Here is an example of defining a sub-circuit in SPICE netlists. The <subckt_name> should be a unique one, which should not be conflicted with any reserved words.
.subckt <subckt_name> <ports>
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.
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.

21
docs/source/fpga_spice/file_organization.rst
View File

@ -1,2 +1,19 @@
Bistream Output File Format
============================
Hierarchy of SPICE Output Files
===============================
All the generated SPICE netlists are located in the <spice_dir> as you specify in the command-line options.
Under the <spice_dir>, FPGA-SPICE creates a number of folders: include, subckt, lut_tb, dff_tb, grid_tb, pb_mux_tb, cb_mux_tb, sb_mux_tb, top_tb, results. Under the <spice_dir>, FPGA-SPICE also creates a shell script called run_hspice_sim.sh, which run all the simulations for all the testbenches.
The folders contain the sub-circuits and testbenches and their contents are shown as following.
Folder Content
include The header files which contain the parameters for stimulate and measurement, as defined in <tech_lib>
subckt Contain all the auto-generated sub-circuits, such as inverters, buffers, transmission gates, multiplexers, LUTs and even logic blocks, connection boxes and switch blocks.
lut_tb Contain all the testbenches for LUTs. This folder is created only when option print_spice_lut_testbench is enabled.
dff_tb Contain all the testbenches for FFs. This folder is created only when option print_spice_dff_testbench is enabled.
grid_tb Contain all the testbenches for logic blocks (grid-level testbenches). This folder is created only when option print_spice_grid_testbench is enabled.
pb_mux_tb Contain the testbenches for the multiplexers inside logic blocks. This folder is created only when option print_spice_pbmux_test-bench is enabled.
cb_mux_tb Contain all the testbenches for the multiplexers inside connection boxes. This folder is created only when option print_spice_cbmux_testbench is enabled.
sb_mux_tb Contain all the testbenches for the multiplexers inside switch blocks. This folder is created only when option print_spice_sbmux_test-bench is enabled.
top_tb Contain the full-chip-level testbench. This folder is created only when option print_spice_top_testbench is enabled.
results An empty folder when created. It stores all the simulation results by running the shell script run_hspice_sim.sh.

2
docs/source/fpga_spice/index.rst
View File

@ -9,4 +9,6 @@
file_organization
spice_simulation
customize_subckt

30
docs/source/fpga_spice/spice_simulation.rst
View File

@ -1,2 +1,32 @@
Run SPICE simulation
====================
2. 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.
total_leakage_srams= -16.4425u
total_dynamic_srams= 83.0480u
total_energy_per_cycle_srams= 269.7773f
total_leakage_power_mux[0to76]=-140.1750u
total_energy_per_cycle_mux[0to76]= -37.5871p
total_leakage_power_pb_mux=-140.1750u
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.
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.
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.

2
docs/source/fpga_verilog/file_organization.rst
View File

@ -1,2 +1,2 @@
Bistream Output File Format
Verilog Output File Format
============================

10
docs/source/index.rst
View File

@ -10,6 +10,16 @@ For more information on the ABC see .
For more information on the VPR see
For more information on the original FPGA architecture description language see
.. toctree::
:caption: Motivation
motivation
.. toctree::
:caption: Getting Started
eda_flow
.. toctree::
:maxdepth: 2
:caption: Extended Architecture Description Language

15
docs/source/motivation.rst Normal file
View File

@ -0,0 +1,15 @@
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.
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.
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.
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].