Added support for successive <> operations overriding each other.

[albert-magyar]

I implemented and tested out both varieties of overriding bulk connects, letting := override <> and letting <> override <>, and I think a good case can be made for the latter.

If :=/procAssign were special-cased to override <>/assign only when no when condition exists, this special overriding assignment would necessarily not be able to be overridden again by a conditional :=, making its meaning more similar to assign than procAssign.

The second way has the tradeoff of requiring multiple calls to assign to succeed, but allowing overriding essentially implies that this is okay. It enforces a few rules:

1. <> can override <> at any part of the hierarchy
2. <> cannot be conditional
3. := cannot override <>

Rule 2 should be enforced even with the existing Chisel semantics, but this case currently produces incorrect results silently. This change also adds a check for this.

[sdtwigg]

Why does <> use a different underlying mechanism for assignment than :=? Perhaps we could extend this commit to cover 2 and 3 as well. It seems like <> should just decompose into a bunch of := operations. I'm not sure what the point is having two assign primitives where one is strictly less-featured than the other.

[aswaterman]

It is not the case that one is less-featured than the other. <> is
direction-agnostic, while := is not. := supports conditional updates,
while <> does not.

On Wed, Apr 16, 2014 at 6:15 PM, Stephen Twigg notifications@github.comwrote:

Why does <> use a different underlying mechanism for assignment than :=?
It seems like <> should just decompose into a bunch of := operations. I'm
not sure what the point is having two assign primitives where one is
strictly less-featured than the other.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/190#issuecomment-40671065
.