Isolation guarantees of combinational groups

[rachitnigam]

@EclecticGriffin and I were thinking about this in the context of the interpreter and the big question is, in the following program:

if port with cond {
  X 
}

what are the isolation guarantees for assignments in cond and X?

1. Should X be able to view assignments within cond? Seemingly the answer is no.
2. What happens with X and cond have overlapping assignments?

Making the answer to both of these as cond is strongly isolated from X means that any RTL implementation of this program needs to run cond in a separate cycle from X which would remove the possibility of optimizations like the one mentioned in #911.

If this is the case, then we need to think about what the value of combination groups, especially for conditionals and loops is.

[sampsyo]

Ah, interesting! I don't know any answers, but I kinda thought that cond was supposed to be "active" throughout the entire duration of the if. In terms of the unfinished "scoped with" idea discussed elsewhere, it would work like this:

with cond {
  if port {
    X
  }
}

…but of course that has weaker isolation guarantees than something more like "cond is only visible at the ~beginning of the if," however we define that. And greater isolation is undoubtedly better.

The answers to @rachitnigam's questions above ("no" and "it's an error") imply a greater isolation that could be desirable. But I'm not quite sure I buy that this policy would require separating the execution of cond and X in time, so cond goes in a cycle all by itself. An alternative would be somewhat like DRF0 for par (cf #921): rather than defining what X does when it tries to read or write the same signals as cond, we just say it's not allowed to do that. (To operationalize that policy: the compiler gets to assume that programs don't do that; the interpreter should probably throw an error for programs that do that; and we can consider building a static checker to flag common cases where it's obvious that this will happen, but it needn't catch every case.)

[rachitnigam]

we just say it's not allowed to do that

Well, that seems to break modular semantics of X–it is allowed to use all these ports except when it is the first group in the branch.

[sampsyo]

I'd say that it just keeps the modular semantics of X on the right-hand side of the wellformedness implication. That is, we already say "in a well-formed program, X does such-and-such." The left-hand side of that implication would just be stronger.

A worse violation of modular semantics would occur if we let X read and write those same signals that are read and written by cond. Then the values X reads and writes would depend on the context it runs in.

So if those are the two choices, we're stuck with two bad options: either the validity of X depends on its context, or the semantics of X depends on its context. One could argue that making the validity context-dependent is less bad than making the semantics context-dependent. But perhaps there is a third way that is even less bad. Or perhaps that visibility into cond is exactly what we want and we should stop fretting about it (i.e., the answers to the questions above should be "yes" and "it's an error, just like any other conflicting assignments").

[rachitnigam]

Ah, after staring at the transitions generated by the lowering pass, I realized that the value of the conditional port needs to be available throughout the execution of the conditional and the loop. @sampsyo was right–the combinational groups needs to be executing during the entire execution of the conditional and loop.

[EclecticGriffin]

Am I incorrect in thinking that this is why the value is stored in a register? Or would it be more accurate to say that storing in a register is a means of realizing this expected behavior? If so, wouldn't it be better to elide the register and keep the comb group active?

[sampsyo]

Yeah, I'd agree that "a register is a means of realizing this expected behavior." You can imagine that sometimes a register would be better, and sometimes keeping the condition active all the time would be better… seems like one of those cost model things.

[EclecticGriffin]

Makes sense, this combined with the par stuff seems to make there be a number of non-local (but non continuous) driven values, at least from the perspective of any given group