Re: Potential Contributions

I think we are wandering back into the discussion about whether blocks 
in a module are concatenated or not.

If analog blocks are concatenated then I would expect the potentials to 
sum, so I think that would be a reasonable way to differentiate 
summing/parallel behavior.  So you could do something like:

module inductor(a,b)
     ...
     branch (a,b) ind;

     analog : L begin // ideal ("L" is block label)
          ...
          V(ind) <+ ...;
     end

`ifdef LOSSY_INDUCTORS
     analog : continue L begin // add losses
          ...
          V(ind) <+ ...;
     end
`endif

endmodule

I think differentiating semantics on whether a branch is named or 
unnamed is a little hard to justify since I'm sure users will miss the 
subtlety of the difference and make mistakes.

Kev.

Ken Kundert wrote:
> Kevin,
>     Indeed, the loop of voltage sources issue is a tangent. Concerning
> the original issue, I would have to say that I am not yet in agreement.
>
> I have wanted multiple analog block in a module to improve the
> modularity of my models. I would like to describe distinct effects each
> in their own analog blocks, and perhaps be able to enable or disable
> them by enabling or disabling the block. I have found this to be
> particularly desirable in Verilog-AMS testbench modules. For example, a
> typical test bench module for a complicated mixed-signal circuit would
> have many have hundreds or thousands of lines of code, and tens or
> hundreds of initial and always blocks that are used to perform
> individual tests and set drive, load, or bias conditions. It is nice to
> be able to group these together, so that, for example, all supply
> related code is together, all stimulus related code is together, etc.
> Consider the supply related code. In a mixed signal design it will
> contain both analog and event-driven behavior. The event driven behavior
> might determine which supply signals should be enabled and the analog
> code would actually create the supply signals for the analog portion of
> the design.
>
> To see why it is undesirable to associate unnamed branches with the
> block rather than the module consider the model of a nonlinear lossy
> inductor. Assume that there is a logical separation of the model into
> code that describes the nonlinear inductor and code that describes the
> loss. If I put these into one analog module (and assuming that they both
> contribute to the potential of the branch) then they would go in series.
> However, if they were each in their own analog blocks they end up in
> parallel, which is not what I wanted.
>
> Presumably I could address this issue in one of two ways. Either I could
>  force them to be combined in series by creating a named branch and have
> them both contribute to that. Or I could combine both effects into a
> single analog block and separate them by placing them both in their own
> named blocks. The former is undesirable because I am forced to use named
> branches. The latter is undesirable because it constrains the modulatity
> (all analog behavior must be adjacent, and cannot be intermingled with
> the event-driven behavior).
>
> The rationalization for associating unnamed branches with analog blocks
> rather than with the module seems a bit of a cop out. It basically
> results in branches from different blocks being combined in parallel.
> But in a multirate setting if we can combine branches in parallel, why
> can't we also combine them in series. Wouldn't the same basic techniques
> apply? And if for some reason we cannot combine them in series, then
> what do we do about named branches declared at the module scope?
>
> One more thing. I noticed in the v2.3 syntax that a named branch cannot
> be declared in an analog block. This, combined with the current
> proposal, implies that unnamed analog branches are associated with
> blocks and named branches are associated with modules. This means that
> named branches would no longer be a superset of unnamed branches. This
> is problematic because the expressive ability of unnamed branches is
> less than named branches, meaning that there will be some things that
> you can do at the module level that you cannot do at the block level.
> That does not seem like a good idea to me.
>
> Instead, I recommend:
> 1. associating the unnamed branches with the module
> 2. specifying the behavior of multirate contributions so that they are
> the same for both named and unnamed branches
> 3. allow named branches to be declared within analog blocks
>
> -Ken
>
> Kevin Cameron wrote:
>   
>> This thread was originally intended to clarify how potential
>> contributions from multiple analog blocks combined, and I  think it's
>> probably gone a bit off topic.
>>
>> If we are in general agreement that potential contributions to a node
>> pair from multiple analog blocks are considered as being in parallel and
>> handling them is left to the simulator (not a language issue) then I
>> think we can move on.
>>
>> Kev.
>>
>>
>> Marq Kole wrote:
>>     
>>> Kev,
>>>
>>> Why would superconducting switches not be supported by the "do
>>> nothing" approach? As stated before, the language allows them, it can
>>> be the solver that refuses. Verilog-A gives you the option to switch
>>> the solver to one that does work for you. Some would rather like to
>>> keep the solver's limitations because it provides valuable feedback on
>>> the structure of the design, other would want to use the solver's
>>> abilities to circumvent certain problems because they know what
>>> they're doing. I do not see the superiority of one view over the
>>> other, and hence it becomes an implementation issue.
>>>
>>> The only restriction is that if you really want to make portable code
>>> you will have to model carefully. When/if SQUIDs and Josephson
>>> junction devices are getting more common we will surely see the market
>>> requiring the solver to handle them correctly. We don't need to change
>>> the language.
>>>
>>> Portable Verilog-AMS code is at this moment restricted by more mundane
>>> notions like how much of the standard is actually implemented in each
>>> compiler/simulator. I propose that once we get to the point that the
>>> solvers actually make the difference in portability we reopen the
>>> discussion. My guess would be no earlier than 5 years from now...
>>>
>>> Cheers,
>>> Marq
>>>
>>>
>>> Marq Kole
>>> Competence Leader Robust Design
>>>
>>> Research
>>> NXP Semiconductors
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *edaorg@v-ms.com*
>>>
>>> Sent by:
>>> owner-verilog-ams@server.eda.org
>>>
>>> 31-01-2007 09:34
>>>
>>>     
>>> To
>>>     verilog-ams <verilog-ams@server.eda-stds.org>
>>> cc
>>>     "Muranyi, Arpad" <arpad.muranyi@intel.com>
>>> Subject
>>>     Re: Potential Contributions
>>> Classification
>>>     
>>>
>>>
>>>
>>>     
>>>
>>>
>>>
>>>
>>>
>>> Muranyi, Arpad wrote:
>>> Can't resist not to chime in...
>>>  
>>> Since when are physical devices ideal?  I.e. when will
>>> a real life voltage source have zero impedance?  Let
>>> me know if you see one, I would like to get one of those.
>>> Superconductors.
>>>
>>> In particular: Josephson Junction logic circuits rely on switching the
>>> state of a SQUID from superconducting to resistive states; in the
>>> superconducting state the SQUID is an ideal 0V source - it switches to
>>> resistive when you drive too much current through it or apply a large
>>> enough magnetic field.
>>>
>>> Here are some links :
>>>
>>> _http://swordfish.eecs.berkeley.edu/markj.www/COSLGate.html__
>>> __http://books.google.com/books?id=8_mngdg77sUC&pg=PA300&lpg=PA300&dq=josephson+junction+%22voltage+state%22+logic&source=web&ots=pFt5FKyaFe&sig=4SvM-ZtRuw77AFK5hdBqNPKsZ3s#PPP1,M1_
>>> <http://books.google.com/books?id=8_mngdg77sUC&pg=PA300&lpg=PA300&dq=josephson+junction+%22voltage+state%22+logic&source=web&ots=pFt5FKyaFe&sig=4SvM-ZtRuw77AFK5hdBqNPKsZ3s#PPP1,M1>
>>> _
>>>  
>>> Also, believe it or not, 0.3+0.6 is NOT equal 0.9!!!
>>> Try this in Matlab:  isequal(0.3+0.6,0.9), the answer
>>> will be a FALSE.  The point is that if the voltage
>>> sources are defined using equations, you may get
>>> inequalities without noticing...
>>> I'm aware of that, but the cases I'm considering (as likely) are those
>>> where some identical components have been instantiated in parallel and
>>> the voltage is more likely derived from parameters  (or zero for
>>> switches), so rounding error mismatch is not likely.
>>>
>>> Kev.
>>>  
>>> I would join the camp that doesn't mess with the ideal
>>> sources with additional series resistors.  In this
>>> day of age, when we are modeling "shorts" as transmission
>>> lines and argue over how good or bad the lossy T-line model
>>> is depending on its algorithms, I would think that a decent
>>> engineer should not expect that two ideal sources connected
>>> in parallel would be a correct netlist.
>>>  
>>> I got curious about the inductor case.  Yes, HSPICE will
>>> bail out with an error if I connect a V source and an
>>> inductor in parallel.  But only if I use an ideal inductor!
>>> Once I define its resistive parasitics like this:
>>>  
>>> L1  n1 n2 L=1nH R=0.001
>>>  
>>> it will work without an error.  This is what I call being
>>> in agreement with physics...
>>>  
>>> Arpad
>>> =============================================================
>>>
>>> _
>>> ------------------------------------------------------------------------
>>> _*From:* __owner-verilog-ams@server.eda.org_
>>> <mailto:owner-verilog-ams@server.eda.org>_
>>> [__mailto:owner-verilog-ams@server.eda.org__] *On Behalf Of
>>> *__edaorg@v-ms.com_ <mailto:edaorg@v-ms.com>_*
>>> Sent:* Tuesday, January 30, 2007 6:49 PM*
>>> To:* verilog-ams*
>>> Cc:* Geoffrey.Coram*
>>> Subject:* Re: Potential Contributions
>>>
>>> Geoffrey.Coram wrote:
>>> Kevin Cameron wrote:
>>>  
>>> According to Marq at least one simulator company has it's simulator
>>> handling this with sharing the current across the sources, I'll presume
>>> that they had some motivation for doing so.
>>>   
>>> Since one simulator actually allowed unequal voltage sources to
>>> be placed in parallel, it is almost certain that this simulator
>>> indeed did place GMIN-like resistors in series with the voltage
>>> sources.
>>>
>>> I would guess the motivation was along the lines:
>>> Customer: hey, why can't I do this?  The voltages are equal!
>>>  What a dumb simulator.
>>> AE: OK, I'll ask R&D to fix it.
>>>
>>> and R&D might not have ever seen the test case, which might
>>> have had exactly the sorts of problems Ken mentions.
>>>  
>>> I'm with the "customer" - if the physics/electronics makes sense it
>>> should be allowed in the HDL, and the simulator should make it's best
>>> effort to handle it.
>>>  
>>> We need a definition of the behavior of parallel potentials for the LRM,
>>> my view is that they should be allowed as long as the potential is
>>> exactly the same and the current will be split evenly across the
>>> potentials (and the user gets a warning). If you disagree propose
>>> something different.
>>>   
>>> As Marq pointed out, the potential is quite likely to be
>>> not exactly equal: 1/1/3 versus 3.  I've also seen cases where
>>> (on Intel machines) one floating-point number is stored in
>>> an 80-bit register in the CPU and compared to a 64-bit number
>>> in the cache, and they don't match in those extra bits.
>>>  
>>> Interesting, but I'd bet 0.0 == 0.0 will always work. Floating point
>>> numbers in Verilog are all supposed to be 64-bit IEEE, so getting a
>>> mismatch with an 80-bit register would be something for the compiler
>>> writers to fix.
>>>
>>> Kev.
>>> -Geoffrey
>>>  
>>> _
>>> ------------------------------------------------------------------------
>>> _
>>> mailto:dkc@grfx.com <mailto:dkc@grfx.com>
>>>
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content by *_MailScanner_* <http://www.mailscanner.info/>*,
>>> and is
>>> believed to be clean. *
>>>
>>> *
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content by **_MailScanner_* <http://www.mailscanner.info/>*,
>>> and is
>>> believed to be clean. *
>>>
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>> believed to be clean. _
>>>       
>
>   


-- 
http://www.grfx.com
mailto:dkc@grfx.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.