If concurrent multiple analog blocks are incorporated into the standard, then I think it should be possible to formally prohibit constructs that result in indeterminate switch branch values. The standard currently says (5.3.1.3): "It is illegal to contribute to an external switch branch from within an analog block." [ Presumably, this means to contribute via a hierarchical out-of-module reference. ] With concurrent multiple analog blocks, we can directly outlaw contributions to switch branches from multiple blocks (straightforward, since everything is in the same translation unit). Alternately, if more flexibility is desired (doubtful), the standard can mandate a combo of elaboration-time and run-time checks on switch-branches that operate in a non-deterministic way. - Boris > edaorg@v-ms.com wrote: >> >> Can you give an example of the issue with switch branches? > > The issue here is something like: > > electrical p,n; > > analog begin : test1 > I(p,n) <+ 5.0; > end > > analog continue : test1 > V(p,n) <+ 0.0; > end > > analog continue : test1 > I(p,n) <+ 3.0; > end > > When contributing to the current I, the switch branch is a > "flow source" and the potential can vary; when contributing > to V, it's a "potential source." It gets slightly more > complicated when one adds if() statements in each analog > block, but the concept is the same. > > If these statements are in the same analog block, then the > LRM already says that the last assignment wins, and also > that when contributing the V, the 5A contrib to I is > discarded, and then when contributing 3A, the V is > discarded (and the 5A stays discarded) -- if one removes > the V-contrib, the two I contribs add (value retention). > > If these are in separate analog blocks, and we're not > concatenating them, then it's hard to know whether one > gets 0V, 3A, 5A, or 8A on that branch. > > -Geoffrey > >Received on Fri Dec 22 11:01:44 2006
This archive was generated by hypermail 2.1.8 : Fri Dec 22 2006 - 11:01:46 PST