-
Notifications
You must be signed in to change notification settings - Fork 4
Config File
In this file, users give information about their circuit to help the tool create a testbench. It's typically named something like my_amplifier_config.yaml. The path to this file will be given to the tool when it runs.
The tests/configs/ folder has some examples, but be warned that some of them have not been updated to the new style. Good examples to look at are:
- Amplifier: tia6.yaml
- Sample and Hold: sampler4.yaml
- Phase Blender: pb.yaml
- Clocked Comparator: LDO_clocked_comparator.yaml
The name of the user's circuit instance. Must match the spice/verilog module name.
Location of the netlist/verilog file. Can be absolute or relative to the config file.
Which template to use. The list of available templates can be found here
Information on which tests to run and which portions of each test to run.
Option 1: Leave it blank and the tool will run all checkpoints for the default tests.
Option 2: List specific tests with a True/False to specify which Fixture should run. If you have run the DC amplifier test before and just want to run the Dynamic test now, you could do so like this:
DCTest: False
DynamicTFTest: True
Option 3: choose which checkpoints of which tests to run. If you would like to skip choosing inputs, for example because you added sample points to input_vectors.csv by hand, you can change the corresponding line to False like so:
DCTest:
choose_inputs: False
run_sim: True
run_analysis: True
run_post_process: True
run_regression: True
If you change something about the way the circuit is modeled (by changing the "optional_input_info" section) then you do not need to re-run the simulation and analysis, only the model fitting. You could do so like this:
DCTest:
choose_inputs: False
run_sim: False
run_analysis: False
run_post_process: False
run_regression: True
More information on each checkpoint can be found on the corresponding wiki page
Here, the user enters information about each input and output to the circuit. This is generally the longest section of the config file. The best way to understand the format is to look at examples in the tests/configs folder. Here are the meanings of the different keywords:
This must correspond exactly with the name in the circuit to be modeled. Buses can be represented with angle or square brackets, with the range inclusive, for example my_bus[2:0] (3 bits), adj<7:0> (8 bits), or ctrl<0:3> (4 bits).
states whether this is an in or out. inout is not supported because the models are always feed-forward; in some cases you can model feedback with an extra port such as an input port for "resistive load".
Can be bit, real, or current, which correspond to digital pins, analog voltage pins, and analog current pins. The high/low values for digital inputs/outputs are specified in the test_config file.
binary: binary-weighted. Assigns a weight to each bit. param = A*bus[0] + B*bus[1] + C*bus[2] + D.
signed_magnitude: binary but with a sign bit. Effectively assigns a weight to each bit when the sign is low, and then a different weight to each bit when the sign is high. TODO this should allow for another line in the config for sign_bit to convey whether the highest or lowest order bit is the sign ... but I think it's not implemented yet and for now always assumes the high-order is the sign.
thermometer: thermometer coded. Assigns a weight to each bit, but will only apply inputs that are valid thermometer codes.
binary_exact: binary-weighted. Rather than assigning a weight for each bit, it assumes that the binary weighting is perfect and assigns a single weight for the slope. param = A*(1*bit[0] + 2*bit[1] + 4*bit[2]) + B. This is not recommended because it can hide bugs that would be exposed with 'binary', but this option might be necessary in cases where there is very little data, e.g. creating a model from the spec.
TODO: one_hot: one-hot encoding scheme. Assigns a weight to each bit, but will only assign one high at a time.
This parameter only applies if the input is a digital bus, and defines the endianness of the bus. The possible values are high and low, and it states which bit becomes a one first when the values counts up from 0 to 1. For a 3-bit bus, high means that a decimal 1 is represented by bus[0]=0, bus[1]=0, bus[2]=1. low would mean a decimal 1 is represented by bus[0]=1, bus[1]=0, bus[2]=0.
This section is the place to define signals that are conceptually important but don't correspond to physical pins (inputs/outputs) on the circuit. The most common use is to define differential/common mode signals. There are several styles of proxy signals:
Define a signal that is a linear combination of other signals. This is how a differential / common mode signal is built.
components: signals which we are building a linear combination of.
coefficients: weights for each of the components.
Examples:
indiff:
style: linear_combination_in
value: (-0.15, 0.15)
components: [inp, inn]
coefficients: [1, -1]
outcm:
style: linear_combination_out
components: [outp, outn]
coefficients: [0.5, 0.5]
Instead of reading an output as an analog voltage, read it as the width of a pulse on a digital output pin. There is an example in sampler4.yaml:
out_0_proxy:
style: pulse_width
reference: out<0>
Pack multiple values into a single vector. Right now this has a very specific purpose, which is to "vector" the required inputs and outputs to a template. The most common use is to turn a template input/output differential.
components: The individual signals to pack into the vector.
Example:
input_test:
style: vector
components: [indiff, incm]
Each template will have a few required pins. This section tells the tool which user circuit pins correspond to those required pins.
This is where you tell Fixture the allowable input range for the various signals. There are 4 possibilities for specifying input ranges:
- A single, fixed value
ibias: 900e-3
The tool will always hold this input to this value, and will not characterize the tool with respect to this input. A common usage is to specify vdd if the user is not interested in characterizing with vdd variation.
- A range of input values
vin: (0.4, 0.8)
The tool will sweep the input over this range. This is the most common option, used for an amplifier's input range, a bias adjustment's input range, etc. When used for a digital bus, the endpoints are inclusive.
- A range and a nominal value
radj<7:0>: (0, 32, 255)
In a tuple of 3 numbers, they are interpreted as (minimum, nominal, maximum). If no nominal is specified (as in option 2), the tool will just assume it's the center of the input range.
- No entry For certain kinds of inputs, such as the clock for a sample-and-hold circuit, no input range needs to be specified.
This section allows users to specify how the final model will depend on each optional input. Each parameter in the model can have an entry in this section, so each one can have a different dependence on optional inputs. There are several options for what that dependence may be:
- No dependence on optional inputs
gain: []
Resulting model: gain = A
- Linear
gain: ['vdd', 'bus']
Resulting model: gain = A + B*vdd + C*bus[0] + D*bus[1] + E*bus[2]
- Nonlinear
gain: ['vdd**2', '1/bus']
Resulting model: gain = A + B*vdd^2 + 1/(C*bus[0] + D*bus[1] + E*bus[2])
Fixture uses sympy to parse the equations, so pretty much anything goes.
- Default: linear with respect to each
# no entry
Resulting model: gain = A + B*vdd + C*bus[0] + D*bus[1] + E*bus[2] + F*ibias
This section collects information specific to the template. For example, the amplifier Template asks for approx_settling_time. The Sampler template has an option to specify clock timing information in this section. If you are missing information, but run Fixture anyway, it will tell you the missing parameters with short descriptions for each one.
When the model used by Fixture is nonlinear, it sometimes has trouble fitting the coefficients. If that happens, you can help the nonlinear optimizer by suggesting values for the coefficients here.
A pointer to another file which has information about interacting with the simulator. Typically you can use one simulator information file for all your circuits.
This worked in an older version of Fixture, but has not been updated since nonlinearity was added. It used to help generate output in a way that was used directly by the DaVE tool mGenero. A pointer to a another file that has the information needed to run mGenero to produce a verilog model of the tool. Theoretically this mgenero_config file should not depend on the user circuit, but it's still a work in progress right now.