From e0c2fc2c8a96a4ccb03b5fbe1ff0aec1a2bbc9df Mon Sep 17 00:00:00 2001 From: Aurelien Alacchi Date: Fri, 12 Oct 2018 15:50:09 -0600 Subject: [PATCH] Documentation_code&example_update --- .../source/arch_lang/link_circuit_modules.rst | 52 +++--- docs/source/arch_lang/multimode_support.rst | 2 + docs/source/arch_lang/spice_sim_setting.rst | 54 +++--- docs/source/arch_lang/tech_lib.rst | 18 +- docs/source/fpga_spice/command_line_usage.rst | 76 +++++--- docs/source/fpga_spice/customize_subckt.rst | 5 +- .../fpga_spice/k6_N10_sram_tsmc40nm_FF.xml | 170 +++++++++--------- .../fpga_spice/k6_N10_sram_tsmc40nm_MC.xml | 170 +++++++++--------- .../fpga_spice/k6_N10_sram_tsmc40nm_SS.xml | 170 +++++++++--------- .../fpga_spice/k6_N10_sram_tsmc40nm_TT.xml | 170 +++++++++--------- vpr7_x2p/libarchfpga/read_xml_arch_file.c | 20 +-- vpr7_x2p/libarchfpga/read_xml_spice.c | 30 ++-- 12 files changed, 487 insertions(+), 450 deletions(-) diff --git a/docs/source/arch_lang/link_circuit_modules.rst b/docs/source/arch_lang/link_circuit_modules.rst index a4127b751..ac5f8563a 100644 --- a/docs/source/arch_lang/link_circuit_modules.rst +++ b/docs/source/arch_lang/link_circuit_modules.rst @@ -1,24 +1,26 @@ 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. +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 Circuit models. 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: +To link the defined circuit 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 circuit model to be linked. And example is shown as follows: .. code-block:: xml - + - - + + -* 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. +* **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. circuit_model_name should match the name of circuit model that have been defined under XML node module_circuit_model. The type of the linked circuit 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. +* **organization:** [scan-chain|memory_bank|standalone], is the type of configuration circuits. + +:numref:`fig_sram` illustrates an example where a memory organisation using memory decoders and 6-transistor SRAMs. .. _fig_sram: @@ -36,30 +38,30 @@ Here is an example. .. code-block:: xml - + 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. +To link a defined SPICE model to a multiplexer in the switch blocks, a new XML property circuit_model_name should be added to the descriptions. Here is an example: .. code-block:: xml - + -* spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models. +* **circuit_model_name:** should match a circuit model whose type is mux defined under module_circuit_models. 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. +To link the defined SPICE model of multiplexer to the Connection Boxes, a circuit_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: @@ -67,48 +69,48 @@ Here is the example: .. code-block:: xml - + -* spice_model_name: should match a SPICE model whose type is mux defined under module_spice_models. +* **circuit_model_name:** should match a circuit model whose type is mux defined under module_circuit_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. +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 circuit model. .. code-block:: xml - + -* spice_model_name: should match a SPICE model whose type is chan_wire defined under module_spice_models. +* circuit_model_name: should match a circuit model whose type is chan_wire defined under module_circuit_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. +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 circuit model. .. code-block:: xml - - + + - + - + -* 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. +* **circuit_model_name:** should match a SPICE model defined under module_circuit_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. +* **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. +* **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. diff --git a/docs/source/arch_lang/multimode_support.rst b/docs/source/arch_lang/multimode_support.rst index 64b04d3d2..de12a8c1b 100644 --- a/docs/source/arch_lang/multimode_support.rst +++ b/docs/source/arch_lang/multimode_support.rst @@ -1,2 +1,4 @@ Modeling Physical Design of Multi-mode Configurable Logic Block Architectures ============================================================================= + +Under construction diff --git a/docs/source/arch_lang/spice_sim_setting.rst b/docs/source/arch_lang/spice_sim_setting.rst index 687d3126d..57e1b410d 100644 --- a/docs/source/arch_lang/spice_sim_setting.rst +++ b/docs/source/arch_lang/spice_sim_setting.rst @@ -11,13 +11,13 @@ The parameters are divided into three categories and can be defined in three XML 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 . +* **sim_temp:** specify the temperature which will be defined in SPICE netlists. In the top SPICE netlists, it will show as .temp . -* 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. +* **post:** [on|off]. Specify if the simulation waveforms should be printed out after SPICE simulations. In all the SPICE netlists, it will show as .option POST when turned on. .. note:: when the SPICE netlists are large or a long simulation 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. +* **captab:** [on|off]. Specify if the capacitances of all the nodes in the SPICE netlists will be printed out. In the top SPICE netlists, it will show as .option CAPTAB when turned on. When turned on, the SPICE simulation runtime may increase. * The XML node @@ -32,16 +32,16 @@ These properties define the options that will be printed in the top SPICE netlis 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]. +* **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. + * 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. :numref:`fig_meas_edge` depicts the definition of the slew and delays of signals and the parameters that can be supported by FPGA-SPICE. @@ -56,11 +56,13 @@ Define stimulates for the clock signal. 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]. +* **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. + * 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:: These slew settings are valid for all the input signals of the testbenches in different complexity levels. .. _fig_meas_edge: @@ -76,11 +78,15 @@ Define the slew of input signals at the rising/falling edge. -* 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. +* **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_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. +* **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 of the node . @@ -90,17 +96,17 @@ Define the slew of input signals at the rising/falling edge. 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. +* **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. +* **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 -* 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. +* **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. + * **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 of the node . @@ -111,9 +117,9 @@ Define the starting and ending point in measuring the slew of a rising edge of a 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. +* **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. +* **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 @@ -121,8 +127,8 @@ Define the starting and ending point in measuring the delay between two signals 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`. +* **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`. +* **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`. diff --git a/docs/source/arch_lang/tech_lib.rst b/docs/source/arch_lang/tech_lib.rst index 3794b55a2..e5d98bc1d 100644 --- a/docs/source/arch_lang/tech_lib.rst +++ b/docs/source/arch_lang/tech_lib.rst @@ -5,30 +5,30 @@ Technology library Declaration -* 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. +* **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. +* **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. +* **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. +* **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 -* 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. +* **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: . 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: . 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. .. code-block:: xml -* 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. diff --git a/docs/source/fpga_spice/command_line_usage.rst b/docs/source/fpga_spice/command_line_usage.rst index 5ddadd74f..2a11f63f6 100644 --- a/docs/source/fpga_spice/command_line_usage.rst +++ b/docs/source/fpga_spice/command_line_usage.rst @@ -2,30 +2,35 @@ 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 Supported Options:: ---fpga_spice ---fpga_spice_dir ---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 + --fpga_spice + --fpga_spice_dir + --fpga_spice_print_top_testbench + --fpga_spice_print_lut_testbench + --fpga_spice_print_hardlogic_testbench + --fpga_spice_print_pb_mux_testbench + --fpga_spice_print_cb_mux_testbench + --fpga_spice_print_sb_mux_testbench + --fpga_spice_print_cb_testbench + --fpga_spice_print_sb_testbench + --fpga_spice_print_grid_testbench + --fpga_spice_rename_illegal_port + --fpga_spice_signal_density_weight + --fpga_spice_sim_window_size + --fpga_spice_leakage_only + --fpga_spice_parasitic_net_estimation_off + --fpga_spice_testbench_load_extraction_off + --fpga_spice_sim_mt_num .. note:: FPGA-SPICE requires the input of activity estimation results (\*.act file) from ACE2. Remember to use the option --activity_file to read the activity file. -.. note:: To dump full-chip-level testbenches, the option –-fpga_print_spice_top_testbench should be enabled. +.. note:: To dump full-chip-level testbenches, the option –-fpga_spice_print_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 grid-level testbenches, the options -- fpga_spice_print_grid_testbench, -- fpga_spice_print_cb_testbench and -- fpga_spice_print_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. +.. note:: To dump component-level testbenches, the options –fpga_spice_print_lut_testbench, --fpga_spice_print_hardlogic_testbench, --fpga_spice_print_pb_mux_testbench, --fpga_spice_print_cb_mux_testbench and --fpga_spice_print_sb_mux_testbench should be enabled. .. csv-table:: Commmand-line Options of FPGA-SPICE :header: "Command Options", "Description" @@ -33,15 +38,36 @@ FPGA Spice Support Options:: "--fpga_spice", "Turn on the FPGA-SPICE." "--fpga_spice_dir ", "Specify the directory that all the SPICE netlists will be outputted to. 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_print_top_testbench", "Print the full-chip-level testbench for the FPGA." + "--fpga_spice_print_lut_testbench", "Print the testbenches for all the LUTs." + "--fpga_spice_print_hardlogic_testbench", "Print the test benches for all the hardlogics." + "--fpga_spice_print_pb_mux_testbench", "Print the testbenches for all the multiplexers in the logic blocks." + "--fpga_spice_print_cb_mux_testbench", "Print the testbenches for all the multiplexers in Connection Boxes." + "-- fpga_spice_print_sb_mux_testbench", "Print the testbenches for all the multiplexers in Switch Blocks." + "--fpga_spice_print_cb_testbench", "Print the testbenches for all the CBs." + "--fpga_spice_print_sb_testbench", "Print the testbenches for all the SBs." + "--fpga_spice_print_grid_testbench", "Print the testbenches for the logic blocks." + "--fpga_spice_rename_illegal_port", "Rename illegal port names" + "--fpga_spice_signal_density_weight ", "Set the weight of signal density." + "--fpga_spice_sim_window_size ", "Set the window size in determining the number of clock cycles in simulation." "--fpga_spice_leakage_only", "FPGA-SPICE conduct power analysis on the leakage power only." - "--fpga_spice_parasitic_net_estimation ", "Default: on. Turn on or off the parasitic net estimation technique." + "--fpga_spice_parasitic_net_estimation_off", "Turn off the parasitic net estimation technique." + "--fpga_spice_testbench_load_extraction_off", "Turn off the load effect on net estimation technique." + "--fpga_spice_sim_mt_num ", "Set the number of multi-thread used in simulation" .. 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." + + + + + + + + + + +BB estimate of min-dist (placement) wirelength: 40 +bb_cost recomputed from scratch: 0.4 +timing_cost recomputed from scratch: 6.94244e-10 +delay_cost recomputed from scratch: 2.76553e-09 \ No newline at end of file diff --git a/docs/source/fpga_spice/customize_subckt.rst b/docs/source/fpga_spice/customize_subckt.rst index f920fb27e..a94c4f6b5 100644 --- a/docs/source/fpga_spice/customize_subckt.rst +++ b/docs/source/fpga_spice/customize_subckt.rst @@ -1,12 +1,13 @@ 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 should be a unique one, which should not be conflicted with any reserved words. .subckt 2. The ports of sub-circuit to be included should strictly follow the sequence: -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 Circuit 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. +.. note:: 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. diff --git a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_FF.xml b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_FF.xml index 59ae9dbda..4a87b8588 100755 --- a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_FF.xml +++ b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_FF.xml @@ -181,23 +181,23 @@ - - + + - - - + + + - - - + + + - - + + @@ -205,119 +205,119 @@ - - + + - - + + - - + + - - + + - + - - + + - - + + - + - + - + - - + + - + - + - + - - - + + + - - + + - - - - + + + + - - + + - - - + + + - - + + - - - + + + - - - - + + + + - + - - - + + + - - + + - - - + + + - + - - + + - - + + - - + + @@ -358,7 +358,7 @@ - + @@ -375,28 +375,28 @@ 2.5x when looking up in Jeff's tables. Finally, we choose a switch delay (58 ps) that leads to length 4 wires having a delay equal to that of SIV of 126 ps. This also leads to the switch being 46% of the total wire delay, which is reasonable. --> - + - + - + - + 1 1 1 1 1 1 1 1 1 - + 1 1 1 1 1 - + 1 1 1 @@ -420,7 +420,7 @@ - + @@ -440,7 +440,7 @@ today and that is when you timing analyze them. --> - + @@ -450,7 +450,7 @@ - + @@ -504,7 +504,7 @@ @@ -520,7 +520,7 @@ - + @@ -544,7 +544,7 @@ - + @@ -559,7 +559,7 @@ - + @@ -584,7 +584,7 @@ Since all our outputs LUT outputs go to a BLE output, and have a delay of 25 ps to do so, we subtract 25 ps from the 100 ps delay of a feedback to get the part that should be marked on the crossbar. --> - + diff --git a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_MC.xml b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_MC.xml index bc1c6ceac..8190908f5 100755 --- a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_MC.xml +++ b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_MC.xml @@ -182,23 +182,23 @@ - - + + - - - + + + - - - + + + - - + + @@ -206,119 +206,119 @@ - - + + - - + + - - + + - - + + - + - - + + - - + + - + - + - + - - + + - + - + - + - - - + + + - - + + - - - - + + + + - - + + - - - + + + - - + + - - - + + + - - - - + + + + - + - - - + + + - - + + - - - + + + - + - - + + - - + + - - + + @@ -359,7 +359,7 @@ - + @@ -376,28 +376,28 @@ 2.5x when looking up in Jeff's tables. Finally, we choose a switch delay (58 ps) that leads to length 4 wires having a delay equal to that of SIV of 126 ps. This also leads to the switch being 46% of the total wire delay, which is reasonable. --> - + - + - + - + 1 1 1 1 1 1 1 1 1 - + 1 1 1 1 1 - + 1 1 1 @@ -421,7 +421,7 @@ - + @@ -441,7 +441,7 @@ today and that is when you timing analyze them. --> - + @@ -451,7 +451,7 @@ - + @@ -505,7 +505,7 @@ @@ -521,7 +521,7 @@ - + @@ -545,7 +545,7 @@ - + @@ -560,7 +560,7 @@ - + @@ -585,7 +585,7 @@ Since all our outputs LUT outputs go to a BLE output, and have a delay of 25 ps to do so, we subtract 25 ps from the 100 ps delay of a feedback to get the part that should be marked on the crossbar. --> - + diff --git a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_SS.xml b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_SS.xml index 74e213373..80b3ad009 100755 --- a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_SS.xml +++ b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_SS.xml @@ -181,23 +181,23 @@ - - + + - - - + + + - - - + + + - - + + @@ -205,119 +205,119 @@ - - + + - - + + - - + + - - + + - + - - + + - - + + - + - + - + - - + + - + - + - + - - - + + + - - + + - - - - + + + + - - + + - - - + + + - - + + - - - + + + - - - - + + + + - + - - - + + + - - + + - - - + + + - + - - + + - - + + - - + + @@ -358,7 +358,7 @@ - + @@ -375,28 +375,28 @@ 2.5x when looking up in Jeff's tables. Finally, we choose a switch delay (58 ps) that leads to length 4 wires having a delay equal to that of SIV of 126 ps. This also leads to the switch being 46% of the total wire delay, which is reasonable. --> - + - + - + - + 1 1 1 1 1 1 1 1 1 - + 1 1 1 1 1 - + 1 1 1 @@ -420,7 +420,7 @@ - + @@ -440,7 +440,7 @@ today and that is when you timing analyze them. --> - + @@ -450,7 +450,7 @@ - + @@ -504,7 +504,7 @@ @@ -520,7 +520,7 @@ - + @@ -544,7 +544,7 @@ - + @@ -559,7 +559,7 @@ - + @@ -584,7 +584,7 @@ Since all our outputs LUT outputs go to a BLE output, and have a delay of 25 ps to do so, we subtract 25 ps from the 100 ps delay of a feedback to get the part that should be marked on the crossbar. --> - + diff --git a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_TT.xml b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_TT.xml index a89d11822..e45fb76f4 100755 --- a/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_TT.xml +++ b/fpga_flow/arch/fpga_spice/k6_N10_sram_tsmc40nm_TT.xml @@ -181,23 +181,23 @@ - - + + - - - + + + - - - + + + - - + + @@ -205,119 +205,119 @@ - - + + - - + + - - + + - - + + - + - - + + - - + + - + - + - + - - + + - + - + - + - - - + + + - - + + - - - - + + + + - - + + - - - + + + - - + + - - - + + + - - - - + + + + - + - - - + + + - - + + - - - + + + - + - - + + - - + + - - + + @@ -358,7 +358,7 @@ - + @@ -375,28 +375,28 @@ 2.5x when looking up in Jeff's tables. Finally, we choose a switch delay (58 ps) that leads to length 4 wires having a delay equal to that of SIV of 126 ps. This also leads to the switch being 46% of the total wire delay, which is reasonable. --> - + - + - + - + 1 1 1 1 1 1 1 1 1 - + 1 1 1 1 1 - + 1 1 1 @@ -420,7 +420,7 @@ - + @@ -440,7 +440,7 @@ today and that is when you timing analyze them. --> - + @@ -450,7 +450,7 @@ - + @@ -504,7 +504,7 @@ @@ -520,7 +520,7 @@ - + @@ -544,7 +544,7 @@ - + @@ -559,7 +559,7 @@ - + @@ -584,7 +584,7 @@ Since all our outputs LUT outputs go to a BLE output, and have a delay of 25 ps to do so, we subtract 25 ps from the 100 ps delay of a feedback to get the part that should be marked on the crossbar. --> - + diff --git a/vpr7_x2p/libarchfpga/read_xml_arch_file.c b/vpr7_x2p/libarchfpga/read_xml_arch_file.c index 5ce0eaaef..c797fb1ac 100644 --- a/vpr7_x2p/libarchfpga/read_xml_arch_file.c +++ b/vpr7_x2p/libarchfpga/read_xml_arch_file.c @@ -1004,9 +1004,9 @@ static void ProcessPb_Type(INOUTP ezxml_t Parent, t_pb_type * pb_type, * We should have a spice_model_name if this mode defines the transistor-level circuit design * Since this is a leaf node */ - pb_type->spice_model_name = my_strdup(FindProperty(Parent, "spice_model_name", FALSE)); + pb_type->spice_model_name = my_strdup(FindProperty(Parent, "circuit_model_name", FALSE)); pb_type->spice_model = NULL; - ezxml_set_attr(Parent,"spice_model_name",NULL); + ezxml_set_attr(Parent,"circuit_model_name",NULL); /* We can read the mode configuration bits if they are defined */ if (NULL != pb_type->spice_model_name) { pb_type->mode_bits = my_strdup(FindProperty(Parent, "mode_bits", FALSE)); @@ -1331,7 +1331,7 @@ static void ProcessInterconnect(INOUTP ezxml_t Parent, t_mode * mode) { } /* Xifan TANG: SPICE Support */ - Prop = FindProperty(Cur, "spice_model_name", FALSE); + Prop = FindProperty(Cur, "circuit_model_name", FALSE); /* Default spice_model will be define later*/ mode->interconnect[i].spice_model_name = my_strdup(Prop); mode->interconnect[i].spice_model = NULL; @@ -1339,7 +1339,7 @@ static void ProcessInterconnect(INOUTP ezxml_t Parent, t_mode * mode) { mode->interconnect[i].fan_in = 0; mode->interconnect[i].fan_out = 0; mode->interconnect[i].num_mux = 0; - ezxml_set_attr(Cur, "spice_model_name", NULL); + ezxml_set_attr(Cur, "circuit_model_name", NULL); /* END */ mode->interconnect[i].line_num = Cur->line; @@ -3056,9 +3056,9 @@ static void ProcessSegments(INOUTP ezxml_t Parent, (*Segs)[i].Rmetal = GetFloatProperty(Node, "Rmetal", timing_enabled, 0); (*Segs)[i].Cmetal = GetFloatProperty(Node, "Cmetal", timing_enabled, 0); /* Xifan TANG: SPICE Model Support*/ - (*Segs)[i].spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", FALSE)); + (*Segs)[i].spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", FALSE)); (*Segs)[i].spice_model = NULL; - ezxml_set_attr(Node, "spice_model_name", NULL); + ezxml_set_attr(Node, "circuit_model_name", NULL); /* Get Power info */ /* (*Segs)[i].Cmetal_per_m = GetFloatProperty(Node, "Cmetal_per_m", FALSE, @@ -3334,9 +3334,9 @@ static void ProcessSwitches(INOUTP ezxml_t Parent, FALSE, 1); /* Xifan TANG: Spice Model Support */ - (*Switches)[i].spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", FALSE)); + (*Switches)[i].spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", FALSE)); (*Switches)[i].spice_model = NULL; - ezxml_set_attr(Node, "spice_model_name", NULL); + ezxml_set_attr(Node, "circuit_model_name", NULL); /* Xifan TANG : Read in MUX structure*/ /* Default, we use tree */ structure_type = FindProperty(Node, "structure", FALSE); @@ -3449,9 +3449,9 @@ static void ProcessDirects(INOUTP ezxml_t Parent, OUTP t_direct_inf **Directs, /* Spice Model Support: Xifan TANG * We should have a spice_model_name for this direct connection */ - (*Directs)[i].spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", FALSE)); + (*Directs)[i].spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", FALSE)); (*Directs)[i].spice_model = NULL; - ezxml_set_attr(Node,"spice_model_name",NULL); + ezxml_set_attr(Node,"circuit_model_name",NULL); (*Directs)[i].line = Node->line; diff --git a/vpr7_x2p/libarchfpga/read_xml_spice.c b/vpr7_x2p/libarchfpga/read_xml_spice.c index f6936e9cb..423e8a417 100644 --- a/vpr7_x2p/libarchfpga/read_xml_spice.c +++ b/vpr7_x2p/libarchfpga/read_xml_spice.c @@ -451,8 +451,8 @@ static void ProcessSpiceModelBuffer(ezxml_t Node, read_spice_model = FALSE; } - buffer->spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", read_spice_model)); - ezxml_set_attr(Node, "spice_model_name", NULL); + buffer->spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", read_spice_model)); + ezxml_set_attr(Node, "circuit_model_name", NULL); /*Find Type*/ Prop = my_strdup(FindProperty(Node, "topology", read_buf_info)); @@ -475,9 +475,9 @@ static void ProcessSpiceModelBuffer(ezxml_t Node, if (0 == strcmp(Prop,"on")) { buffer->tapered_buf = 1; /* Try to dig more properites ...*/ - buffer->tap_buf_level = GetIntProperty(Node, "tap_buf_level", TRUE, 1); + buffer->tap_buf_level = GetIntProperty(Node, "tap_drive_level", TRUE, 1); buffer->f_per_stage = GetIntProperty(Node, "f_per_stage", FALSE, 4); - ezxml_set_attr(Node, "tap_buf_level", NULL); + ezxml_set_attr(Node, "tap_drive_level", NULL); ezxml_set_attr(Node, "f_per_stage", NULL); } else if (0 == strcmp(FindProperty(Node,"tapered",TRUE),"off")) { buffer->tapered_buf = 0; @@ -584,16 +584,16 @@ static void ProcessSpiceModelPort(ezxml_t Node, ezxml_set_attr(Node, "is_config_enable", NULL); /* Check if this port is linked to another spice_model*/ - port->spice_model_name = my_strdup(FindProperty(Node,"spice_model_name",FALSE)); - ezxml_set_attr(Node, "spice_model_name", NULL); + port->spice_model_name = my_strdup(FindProperty(Node,"circuit_model_name",FALSE)); + ezxml_set_attr(Node, "circuit_model_name", NULL); /* For BL/WL, BLB/WLB ports, we need to get the spice_model for inverters */ if ((SPICE_MODEL_PORT_BL == port->type) ||(SPICE_MODEL_PORT_WL == port->type) ||(SPICE_MODEL_PORT_BLB == port->type) ||(SPICE_MODEL_PORT_WLB == port->type)) { - port->inv_spice_model_name = my_strdup(FindProperty(Node, "inv_spice_model_name", FALSE)); - ezxml_set_attr(Node, "inv_spice_model_name", NULL); + port->inv_spice_model_name = my_strdup(FindProperty(Node, "inv_circuit_model_name", FALSE)); + ezxml_set_attr(Node, "inv_circuit_model_name", NULL); } return; @@ -830,8 +830,8 @@ static void ProcessSpiceModel(ezxml_t Parent, if (Node) { spice_model->pass_gate_logic = (t_spice_model_pass_gate_logic*)my_malloc(sizeof(t_spice_model_pass_gate_logic)); /* Find spice_model_name */ - spice_model->pass_gate_logic->spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", TRUE)); - ezxml_set_attr(Node, "spice_model_name", NULL); + spice_model->pass_gate_logic->spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", TRUE)); + ezxml_set_attr(Node, "circuit_model_name", NULL); FreeNode(Node); } else if ((SPICE_MODEL_MUX == spice_model->type) ||(SPICE_MODEL_LUT == spice_model->type)) { @@ -883,9 +883,9 @@ void ProcessSpiceSRAMOrganization(INOUTP ezxml_t Node, return; } - cur_sram_inf_orgz->spice_model_name = my_strdup(FindProperty(Node, "spice_model_name", required)); + cur_sram_inf_orgz->spice_model_name = my_strdup(FindProperty(Node, "circuit_model_name", required)); cur_sram_inf_orgz->spice_model = NULL; - ezxml_set_attr(Node, "spice_model_name", NULL); + ezxml_set_attr(Node, "circuit_model_name", NULL); /* read organization type*/ Prop = FindProperty(Node, "organization", required); @@ -1259,14 +1259,14 @@ void ProcessSpiceSettings(ezxml_t Parent, ProcessSpiceTechLibTransistors(Parent, &(spice->tech_lib)); /* module spice models*/ - Node = FindElement(Parent, "module_spice_models", FALSE); + Node = FindElement(Parent, "module_circuit_models", FALSE); if (Node) { - spice->num_spice_model = CountChildren(Node, "spice_model", 1); + spice->num_spice_model = CountChildren(Node, "circuit_model", 1); /*Alloc*/ spice->spice_models = (t_spice_model*)my_malloc(spice->num_spice_model*sizeof(t_spice_model)); /* Assign each found spice model*/ for (imodel = 0; imodel < spice->num_spice_model; imodel++) { - Cur = FindFirstElement(Node, "spice_model", TRUE); + Cur = FindFirstElement(Node, "circuit_model", TRUE); ProcessSpiceModel(Cur, &(spice->spice_models[imodel])); FreeNode(Cur); }