Re: Verilog-AMS Committee Meeting Minutes - Dec 22 2006

From: Boris Troyanovsky <boris_at_.....>
Date: Fri Dec 22 2006 - 10:16:53 PST
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