[SV] Generate case/if blocks

[teqdruid]

I need to emit verilog which selects a module to instantiate based on a module parameter. I think the only way to do that is a generate block like:

  generate
  begin
    if (__INST_HIER == "top.child[0]")
    begin
      Child_dst2_width8_pipedepth3 impl(.clk(clk));
    end
    else if (__INST_HIER == "top.child[1]")
    begin
      Child_dst2_width8_pipedepth4 impl(.clk(clk));
    end
    else if (__INST_HIER == "top.genchild[0]")
    begin
      Child_dst3_width32_pipedepth4 impl(.clk(clk));
    end
    else if (__INST_HIER == "top.bar")
    begin
      Child_dst3_width32_pipedepth4 impl(.clk(clk));
    end
    else
      $fatal(1, "%m: Could not find specialized module for %s", __INST_HIER);
  end
  endgenerate

(I just learned that I can use a case statement instead of ifs, but same difference.)

Is there some other way for me to achieve the desired result which we currently support? If not, I'll have to go about adding support for generate blocks, yes? (Or am I just not seeing it?) Should I use the existing sv.if or sv.case ops (inside of the generate op Block). They only support integer conditions (so they're synthesizable). Should I make them more generic?

I'm pretty sure the answers to my questions are 'no', 'correct', ('you're not blind'), and 'yes', respectively. The SV dialect is intended to be more AST/syntactic than logical, right? I wanted to check before I put in the work.

[teqdruid]

@darthscsi I suspect you're best equipped to answer this question.

[teqdruid]

TIL that apparently generate is optional in SV. This works and has the desired behavior:

  case (__INST_HIER)
    "top.child[0]":
      Child_dst2_width8_pipedepth3 impl(.clk(clk));
    "top.child[1]":
      Child_dst2_width8_pipedepth4 impl(.clk(clk));
    "top.genchild[0]", "top.bar":
      Child_dst3_width32_pipedepth4 impl(.clk(clk));
    default: 
      $fatal(1, "%m: Could not find specialized module for %s", __INST_HIER);
  endcase

(Wherein __INST_HIER is a module parameter.)

So all I'd have to do is relax the $cond type on sv.if and/or sv.case!

[darthscsi]

We will certainly need to have generate statements in sv. I think generate ifs have more features than normal ifs, if so, then a generate.if might make sense. Even if they are the same syntax, it might make sense to keep them as separate ops to make nesting and checking easier. I'm not sure, but like ifdef and ifdef.procedural.

There's also the matter of loops and generates and if's and always blocks in general being able to have labels and those labels being used to refer to things declared inside. This is likely some systematic update to the sv dialect we need, which will need careful thought w.r.t. inner refs (more complex nesting), and SSA uses of things inside generates (especially loops where a single decl is actually multiple decls when viewed from outside).

[darthscsi]

Declarations in an ifdef with uses outside has already caused some discussion on scoping and such, but generate will be significantly more subtle.

[teqdruid]

We will certainly need to have generate statements in sv. I think generate ifs have more features than normal ifs, if so, then a generate.if might make sense. Even if they are the same syntax, it might make sense to keep them as separate ops to make nesting and checking easier. I'm not sure, but like ifdef and ifdef.procedural.

Yes, I agree. Generate-(if/case) are completely different constructs in SV. For instance, they only support constant conditions and constant case values, so we'd want to model them as Attributes rather than Values.

There's also the matter of loops and generates and if's and always blocks in general being able to have labels and those labels being used to refer to things declared inside. This is likely some systematic update to the sv dialect we need, which will need careful thought w.r.t. inner refs (more complex nesting), and SSA uses of things inside generates (especially loops where a single decl is actually multiple decls when viewed from outside).

Yep.

Declarations in an ifdef with uses outside has already caused some discussion on scoping and such, but generate will be significantly more subtle.

I remember. I think we can start by not supporting the full generality of SV generate blocks.

I'll open a PR with some strawman code. Hopefully we can develop this feature incrementally and accept that not everything will work at first.

[teqdruid]

I've put together a PR which has basic support for generate-cases. Please comment in that PR on the basic support.

On InnerRefAttr and GlobalRefs: I included both a generate label and individual case labels. I'm thinking we need to add an optional namespace ArrayAttr to InnerRefAttr. In the case of generates, the first namespace array element would be the generate block name and the second would be the case name. Then the name would operate as normal within each case region. Does this sound reasonable?

As for SSA values on the inside: for this case specifically, we can skirt the issue by using sv.wire, write to it inside, and read from it outside. Longer term, we probably want some sort of phi node.

What Are the other subtleties which need to be reasoned about? I'm no longer familiar with the core infra.