Logic Synthesis Configuration

This section of the configuration file specifies options for circuit synthesis. It contains some options that are used by all synthesis styles, as well as some that are used by Maelstrom, the latest synthesis style for CHP.

Most of the options in this file are technology-specific. The configuration file name is synth.conf. The entire set of parameters are surrounded by begin synth and end.

Pure structures in ACT are synthesized to an integer, whose bitwidth is the sum of the bitwidths of the member fields. In order to implement channels of a pure structure type, we define a new type that contains an integer channel as a member. This string is the name of that member.

string struct_chan_name "CS" 

This is needed since the integer of sum-of-fields bitwidth will not be an implementation the pure structure type, in accordance with ACT's type system.

The entire set of parameters in this section are surrounded by begin ring and end.

int verbose 0

This controls the verbosity level in the output from Maelstrom. Setting this to 1 triggers some additional comments in the output ACT file that are useful for debugging and seeing the correspondence between printed circuits and CHP.

The entire set of parameters in this section are surrounded by begin bundled and end.

int buffer_latch_reads 0

The outputs of latches are the only locations where the fanout can grow unexpectedly. Setting this option to 1 causes every read of a variable to be buffered, i.e. a signal buffer is placed on the output of the latch and the output of that is used, instead of using the output of the latch directly. This can be used to diagnose slew issues due to high fanout, but note that this will result in a high overhead from the inserted buffers themselves. Turning this on is not recommended in a tapeout flow and a complete buffer insertion algorithm should be used instead.

Maelstrom internally uses multiple delay line topologies, which can be specified in $ACT_HOME/syn/ring/delay_lines.act. The user can also specify the delays at which Maelstrom must switch from using one topology to the next. Effectively, one can provide a continuous, monotonically increasing piecewise linear (PWL) curve of template-parameter vs. delay in the form of (x,y) pairs where each line segment in the curve corresponds to one topology.

int delay_line_types 4

This is the number of pieces in the PWL curve.

int_table delay_params_L 0   5000     10000    50000     100000
int_table delay_offsets_L 0   5000     10000    50000     100000
real_table delay_vals_L  0.0 50000.0  100000.0 500000.0  1000000.0

The suffix L indicates that this triplet of tables is for the latch-based datapath. The table delay_vals corresponds to the y-values in the (x,y) pairs. The tables delay_params and delay_offsets jointly determine the x-values in the (x,y) pairs. The delay_params values denote the bounds of template parameters for that particular delay line topology. The delay_offsets allows for the shifting of the delay curve of that particular topology to match the entire PWL curve. In order to see the precise relation, consider this ACT process which is a wrapper for a delay line topology:

export template <pint N>
        defproc delay_line_0(bool? in; bool! out)
        {
            { N >= Delay_Params[0] : "Param out of range for this delay line" };
            { N <  Delay_Params[1] : "Param out of range for this delay line" };
            pint N_loc = N - Delay_Params[0];

            // put your delay line here in terms of N_loc -------
            pint my_N = N_loc+Delay_Offsets[0];
            std::delay_lines::chain_delay_buffer<my_N> ic(in, out);
            // put your delay line here in terms of N_loc -------
        }

real pulse_width 210.0

This specifies the desired width, in picoseconds, of the pulse generator's pulse, that is used to briefly open and close latches in the latch-based datapath. This is used for the 4-phase and the 2-phase latch datapaths.

real capture_delay 210.0

This specifies, in picoseconds, the time it takes for a LATCH cell to capture a value.

# inputs:                 2      3      4      5      6      7      8     9+    
real_table mux_delays 96.43 102.36 106.81 135.41 135.41 208.68 230.97 2000.0

This table specifies, in picoseconds, the delay of the MUXes used in the generated circuit to merge values of variables at the end of selections. The first entry corresponds to a 2-input MUX, with successive entries incrementing the number of inputs by 1. The last entry is used for any MUXes of that size or larger. These are extracted from SPICE simulations of merge_mux_ohc_opt process in the circuit library.

# inputs:              0   1     2     3     4      5      6      7      8    9+               
real_table or_delays 0.0 0.0 66.12 86.47 89.87 108.46 119.20 139.24 213.70 500.0

This table specifies, in picoseconds, the delay of an N-input OR-gate. These are extracted from SPICE simulations of the ortree process from the ACT standard library.

real send_delay 40.0
real recv_delay 40.0
real assn_delay  0.0

# way:                  0   1    2    3    4    5    6    7    8   9+               
real_table sel_delays 0.0 0.0 20.0 30.0 40.0 50.0 60.0 70.0 80.0 90.0

These are used for producing delay estimates for annotated simulation of CHP and for informing timing-driven microarchitecture optimization of CHP. The first three numbers, in picoseconds, specify the delays of the controller circuits for the 3 elementary statements in CHP. Due to latch elimination, the assignment controller delay is zero. The table corresponds to the sums of the delays of the selection split and merge controllers.