Externally-provided parameters

[UnsignedByte]

One of the cool things about the existential parameter feature is that parameters no longer need to be "threaded" downward from the toplevel through many components, and it is used at the moment in the gen framework, where the user can build filament components working for a whole space of possible designs.

This behavior is currently only available to special gen tools, however, and in practice all existential parameters inside a filament component are specified within the component (usually as some blackbox function of the input parameters). I think it would be a feature to allow the user to tweak these externally. For example, when working on the FFT we may implement multiple versions of the butterfly unit, which, in the code looks something like this:

comp Butterfly[W, E, ?M=W-E-1]<'G: II>(
  go: interface['G],
  in0[2]: ['G, 'G+II] W, // real and imaginary parts of input
  in1[2]: ['G, 'G+II] W,
  twiddle[2]: ['G, 'G+II] W // twiddle factor
) -> (
  out0[2]: ['G+L, 'G+L+1] W,
  out1[2]: ['G+L, 'G+L+1] W
) with {
  // ...
} where
    // ...
{
  // switches between the type of butterfly unit
  let T = 1;
  if T == 0 {
    // streaming version
    // ...
  } else if T == 1 {
    // iterative version
    // ...
  } else {
    // ...
  }
}

We manually swap between these to test different behavior and to get different results. It would be nice if parameters like these could be tweaked externally, so something like #435 can tweak them. Currently #440 allows us to thread T up to the main component and tweak it in that way, but this defeats the whole purpose of existential components.

Ideally, I would think that these parameters should provide the same hook as gen config parameters, allowing the user to control them via some configuration file. We could possibly put this in the with section of a component, something like

with {
  extern T = 1; // default value for T is 1, can be changed
}

and then from the config:

[params.Butterfly]
T = 0

[UnsignedByte]

This would make for example the evaluation code from the paper way easier to implement - we would simply have externally provided parameters to change whether we are using XLS, Flopoco, filament for floating point, whether we want streaming or iterative, etc.

We could even use something like bayesian optimization to automatically optimize these designs.

[UnsignedByte]

I propose a syntax possibly like follows:

comp Butterfly[W, E, ?M=W-E-1]<'G: II>(
  go: interface['G],
  in0[2]: ['G, 'G+II] W, // real and imaginary parts of input
  in1[2]: ['G, 'G+II] W,
  twiddle[2]: ['G, 'G+II] W // twiddle factor
) -> (
  out0[2]: ['G+L, 'G+L+1] W,
  out1[2]: ['G+L, 'G+L+1] W
) with {
  extern T = 1; // 1 is the default value
  // ...
} where
    // ...
{
  // switches between the type of butterfly unit
  if T == 0 {
    // streaming version
    // ...
  } else if T == 1 {
    // iterative version
    // ...
  } else {
    // ...
  }
}

And from a config toml:

[Butterfly]
T = 1

[UnsignedByte]

We can also rewrite some of the gen interfaces to allow us to specify this as an extern which would be really cool!

[rachitnigam]

I guess one of the challenges here is whether we are defining this at the component or instance-level? Both the mechanisms above focus on the component-level solution which means all instances will use the same value for the output parameter.

I think PyMTL uses some sort of glob syntax to specify the value of parameters to provide instance level parameterization:

# All butterflies in C0 use 1
[main.C0]
Butterfly.T = 1

# All butterflies in C1 use 2
[main.C1]
Butterfly.T = 2

# All shuffles everywhere use 3
[main.*]
Shuffle.L = 3

Of course, now you have the problem of ensuring that these specifications don't overlap.

We can also rewrite some of the gen interfaces to allow us to specify this as an extern which would be really cool!

Do you have thoughts on what this would look like?