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. _ > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 - 12:03:32 PST