Investigate procedural approach to generics in HIRN

[Jacajack]

[Jacajack]

Okay, so my conclusion so far is that it's not gonna be nice at all. To implement fully procedural generic resolution we'll need ordering of assignments, if and for statements in HIRN. Consider the following:

int n;
int k = 1;
if (k > 4) {n = 11;} else {n = 12;} // (1)
int m = n;  // (2)
// cannot reorder (1) and (2)

Impact on codegen

localparam constants can only be assigned at declaration. That implies they cannot be assigned to from a generate block. However, the assigned value can be a return value from a SV function. Considering that our generic variables could be assigned to from an inner conditional scope, we need ability to extract relevant scopes and translate them into SV function which mimic behavior of our generic variable. The example above should be translated into something along these lines:

function hirn_generic_n$(int k);
  int n;
  if (k > 4)
    n = 11;
  else
    n = 12;
  return n;
endfunction

function hirn_generic_k$();
  int k;
  k = 1;
  return k;
endfunction

function hirn_generic_m$(int n);
  int m;
  m = n;
  return m;
endfunction

// Ordering based on dependencies
localparam k = hirn_generic_k$();
localparam n = hirn_generic_n$(k);
localparam m = hirn_generic_m$(n);

This strange approach is a result of SV's generate blocks being semantically non-equivalent to our if and for blocks. Their purpose is to generate hardware instances and not execute code in a procedural manner - they have functions for that. We've decided to merge these two concepts, which makes it more intuitive but makes the codegen harder at the same time.

The benefits

Generating SV functions opens many new doors for us. One example would be parameter up-propagation. Currently generic outputs from modules are banned. This is a major limitation of SV as well. This can be worked around by providing associated functions for modules with generic outputs:

module X {
  input int x;
  output int y;
}

impl X {
  y = x + 17;
}

could result in following SV output:

function X_generic_out_y(int x);
    return x + 17;
endfunction

module #(parameter x = 'x) X;
endmodule

and then, we could compile code such as:

int x = 14;
int y;
X xmod {x, y};

to

localparam x = 14;
localparam y = X_generic_out_y(x);
X #(.x(x)) xmod; // forgive the lack of intermediate vars

This isn't anything revolutionary since we already support generic expressions in module interfaces but seems like a nice supplement.

Compromise approach

The following assumptions make it possible for us to implement generic based on the current signal-like semantics and then smoothly transition to procedural-like approach without breaking backwards compatibility:

1. Every generic variable is assigned to exactly once
2. Generic variable must not be used before it is assigned to
3. Generic variable must be assigned to in the same scope where the declaration is

Moreover, these assumptions make implementing function-free SV codegen. The only ugly side-effect is that localparams need to be sorted based on generic variable inter-dependencies. This can be performed locally for each scope and does not require scope dependency resolution (which is an another major advantage).

[Jacajack]

@WojciechPtas do localparam assignments need to be sorted in the codegen or can we rely on ordering from HIRL for now? Just wanted to know how important the issue should be.

Nevermind, we can't:

module a {}
impl a {
	int n, k;
	k = 16;
	n = k;
}

module a;
        localparam logic[63:0] n = k;
        localparam logic[63:0] k = 64'h10;
endmodule

It even compiles in SV, but I'm not sure if I want to know why. (oh god it even works)

[WojciechPtas]

I agree with the conclusions, not much to be added here. Hirl already implements the first two assumptions.
Third one will be added today

[WojciechPtas]

From my side, all needed checks are introduced in nearest PR #242