xcell is a cell library characterizer. It takes in a configuration file (xcell.conf) and an ACT file that is used to provide the list of cells to be characterized, and runs a large number of SPICE simulations to generate timing and energy tables in the .lib file format.
Cells are defined in ACT using defcell. The ports to cells should only use boolean variables, and direction flags should be specified so that tools know which ports correspond to inputs v/s outputs. The following is an example of a buffer cell:
defcell BUFX2 (bool? A; bool! Y) { bool _Y; prs { A => _Y- _Y => Y- } sizing { _Y{-1}; Y{-2} } }
The name of the cell is BUFX2, with an input signal A and
an output signal Y. Internally, the cell also has signal _Y but
this is not exposed via its port list. The circuit is specified using the production rule syntax, and includes a sizing body that is used to compute the transistor sizes for the circuit.
xcell can characterize cells that are comprised of combinational gates. It can also characterize cells that include state-holding gates in a limited way. The restriction on state-holding cells is: (i) every input to a state-holding production rule in the cell is combinationally determined from the primary inputs to the cell; (ii) the output of the state-holding gate and/or its inverted version is a primary output of the cell. For these types of cells, xcell can automatically compute timing arcs that need to be characterized. Characterization entails computing a trajectory, which is a sequence of input changes that includes the timing arc to be characterized (details available).
For more complex cells, the user must specify the characterization trajectory in the xcell.conf configuration file.
Typically the configuration file is found in the directory where xcell is to be run, and is named xcell.conf. This uses the standard ACT configuration file syntax. All parameters should be placed between a begin xcell and end directive.
# example xcell configuration begin xcell # config goes here end
By default xcell assumes that models.sp exists in the ACT configuration directory for the technology. This SPICE file should include the SPICE models used for circuit simulation, along with any technology-specific option settings. A user-defined SPICE file can be used instead as follows:
string tech_setup "my_spice.sp"
This will use my_spice.sp as the SPICE deck that should be included to load all the technology information.
string corner "TT"
This specifies the process corner name to be included in the .lib file output.
real Vdd 1.8
This specifies the power supply voltage to be used during characterization.
real T 298
This specifies the temperature (in Kelvin).
real P_value 1.0
This specifies the process value for the .lib file.
The input capacitance of a gate is characterized by computing the RC delay used to switch it. The characterization resistor is specified using the parameter below.
real R_value 100 # in KOhms
The units for the .lib file can also be specified. The example below uses microWatts for power, KOhms for resistance, picoseconds for time, etc.
begin units real power_conv 1e-6 real resis_conv 1e3 real time_conv 1e-12 real cap_conv 1e-15 real current_conv 1e-6 end
Waveforms used for characterization and transit time threshold computations for rising and falling edges are specified as below.
begin waveform # 20% to 80% real rise_low 20 real rise_high 80 real fall_high 80 real fall_low 20 end
Maximum transition time for a signal change in “time” units
real default_max_transition_time 1000
Measurement window period (in ps)
real period 25000
… within a measurement window, each signal change is separated by this amount of time (in ps). Period must be at least 4 times this amount.
real short_window 4000
For leakage, ignore transients on either end of the period when taking the average leakage power (in ps). Period needs to be larger than 4 times leak_window
real leak_window 4000
Input capacitance estimation use RC delay to estimate C. Wait for signal to rise/fall with 10% of Vdd/GND, and so set to 0.1
real cap_measure 0.1
Table points for input slew and external load:
real_table input_trans <val0 val1 ...> real_table load <val0 val1 ...>
By default, xcell assumes that Xyce will be used for characterization. For readability, we recommend to pass it explicitly as:
string spice_binary "Xyce" int spice_output_fmt 0
To run the hspice simulator (remember to setup synopsys):
string spice_binary "hspice" int spice_output_fmt 1
The variable spice_output_fmt sets the output format, which is of type .raw for Xyce and .tr0 for hspice.
xcell also uses the lint.conf file for the technology. This file contains the parameters V_high and V_low, which are used to convert analog waveform values into digital signals. xcell re-computes the Boolean function implemented by the cell via SPICE simulations as a sanity check, and these voltage thresholds are used to determine the logic levels of output signals.
xcell takes an ACT file as input. This ACT file should contain a process called characterize, and the cells to be characterized are instantiated within the process.
import globals; /* import or specify your cells here */ defproc characterize() { mycells::cell0 g1; mycells::cell1 g2; } characterize c;
The instances within characterize() must be named g1, g2, etc. xcell will walk through these instances until it cannot find the next instance, and characterize each instance as a cell.
Suppose you have the layout of a C-element and an extracted SPICE/HSPICE netlist with parasitics.
This paragraph walks through the setup files that are necessary to run an automatic cell characterization using xcell on an external SPICE/HSPICE netlist.
In addition to the standard xcell.conf and top-level ACT file that specifies the cells to be characterized, you will need the following:
wrapper.spmyxcell.confThe command to run is
xcell -cnf=myxcell.conf top_level.act out
When the cell name is printed to the terminal, you should see :
Cell: name-goes-here [external]
xcell generates the simulation SPICE deck based on prs2net, hence the port connections are made in the same order as prs2net would write them. You can inspect the port connection order by running the following command and inspecting the generated prs2net_netlist.sp:
prs2net -p characterize top_level.act > prs2net_netlist.sp
The power sources are generated by xcell as global variables and are called GND and Vdd. If your external netlist names the power connections differently, instantiate your cell in a spice wrapper and pass the power connections to your cell's instance like in the following example:
# wrapper.sp .include "_0_0cell_0_0g0n1n2n3naaa__023aox0.pex.netlist" .subckt _0_0cell_0_0g0n1n2n3naaa__023aox0 IN_50_6 IN_51_6 IN_52_6 IN_53_6 OUT xg1 IN_50_6 IN_51_6 IN_52_6 IN_53_6 OUT GND Vdd +_0_0cell_0_0g0n1n2n3naaa__023aox0_pex .ends
Note that:
prs2net expects, declared in the same order.prs2net generates for that cell from the ACT file.
Declare the external netlist in a custom configuration file, and keep the general parameters in xcell.conf (you could put everything in xcell.conf but this might be cleaner).
## myxcell.conf
# this should be taken from lint.conf, but in case you don't have it...
begin lint
real Vdd 1.2
real V_high 0.8*Vdd
real V_low 0.2*Vdd
real hysteresis 0.0
end
begin xcell
begin cells
begin ::cell::g0n1n2n3naaa__023aox0<>
string spice "wrapper.sp"
int type 0
end
end
end
Note: xcell.conf must be located in the same directory where you run xcell.
The following is an example of a cell that needs special support for characterization.
begin cells
# the full ACT name of the cell
begin ::syn::var_one_bit<f>
# for an external netlist, uncomment the next line
# string spice "mycell.sp"
# characterization arcs
begin scenario
# scenario format
# input-pin# (0,1,...#inputs-1)
# in_init_value (0/1)
# output-pin# (0,1,...#outputs-1)
# out_init_value (0/1)
# length (2,3, or 4: length of scenario)
# state1 (input truth-table format encoded as an integer)
# state2
# ...
# stateN
int_table dynamic 0 0 0 0 3 2 0 1 \
0 0 1 1 3 2 0 1 \
1 0 0 1 3 1 0 2 \
1 0 1 0 3 1 0 2
string_table function "wt*!wf*!Reset + !wt*!wf*!Reset*dt" \
"wf*!wt*!Reset + !wt*!wf*!Reset*df"
end
end
end
The dynamic table specifies the scenarios to be run through for characterization. Each scenario corresponds to applying an input vector and running a SPICE simulation for the pre-specified amount. Scenarios can be of length 2, 3, or 4. For example, a simple combinational gate would have a scenario of length two:
(State-holding gates can require more complex scenarios for characterization.)
The input vector is specified as an unsigned integer that corresponds to the values of all the input bits. The order is the same order as in the SPICE cell corresponding to subcircuit for the cell generated by ACT (e.g the same output order as you would find by running prs2net). To set input 0 to 1, 1 to 1, 2 to 0 would correspond to the bit pattern 011 (lab = bit 0), and hence the integer 3.