owner-verilog-ams@server.eda.org wrote on 18-04-2007 22:52:38: <snip> > If > The behavior of an analog blocks should not change if they are moved > from separate modules into the same module. > holds, then > If you contribute to the potential of a branch in two analog blocks, > the values add; if you put the analog contrib statements into > separate modules, the potentials are in parallel. > is untrue. Then one should conclude that the above proposition (The behavior ... same module) is false. The reason that it is false is that the contribution statements involving unnamed branches refer to separate unnamed branches in the case of separate modules, but refer to the same module-level branches in the case of multiple concurrent analog blocks. The conclusion is that the behavior of analog blocks does change if they are moved from separate modules into the same module BUT IN SEPARATE CONCURRENT ANALOG BLOCKS. The fact that we propose separate approaches to concurrent and concatenated analog blocks is a dead giveaway of this distinction. > Since there is no prior specification for the behavior for multiple > analog blocks in the same module I propose that the contributions > are in parallel for consistent behavior. Where the branch is > declared is immaterial. Well, the committee members available in the telecon of April 12 propose that the contributions act as described in the minutes of that call. We agreed that the declaration of the branch IS important as suggested and made plausible by Ken in his posting from January 31st. (see http://www.eda-stds.org/verilog-ams/hm/1922.html) > You would only get that problem if you were automatically > concatenating analog blocks - but we are not doing that so there is > no issue, and no need to disallow multiple switch branches. The problem is in the combination of switch branches, concurrency and value retention, but we've been through these moves before as in the email thread started on January 26th. (see http://www.eda-stds.org/verilog-ams/hm/1893.html) Marq -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Apr 18 14:23:13 2007
This archive was generated by hypermail 2.1.8 : Wed Apr 18 2007 - 14:23:19 PDT