Kevin - I don't think you've been following this discussion: where did interconnect come from?? The question was related to instantiating spice primitives in Verilog-AMS. If you're doing an electrical circuit, you're OK. But, suppose you now want to model a mechanical or thermal system (perhaps in conjunction with electrical: a MEMS device or self-heating). The "resistor" is now friction or a thermal conductance, and the simulator needs to know this to set the appropriate tolerances (and suppress warnings about incompatible disciplines). We're using attributes to indicate that the ports of the resistor aren't electrical in these cases. And we're using the built-in resistor rather than defining our own modules. -Geoffrey K. Cameron [SV] wrote: > > Given that interconnect is essentially type-neutral (or should be) and a > net should flatten to a single node in the simulator, what are you > actually trying to put an attribute on here? > > If you want to put this info somewhere I suggest looking at using module > prototypes and/or macromodules and putting it in headers rather than on > the instance. > > Kev. > > Marq Kole wrote: >> >> Martin, >> >> There is still the issue that the current syntax does not allow an >> attribute on a module instance. Your example is not legal Verilog, >> according to the IEEE 1364-2005 LRM. I do not think we should >> introduce this new syntax as that would make the module instantiation >> for AMS different from the IEEE 1364-2005 one. I presume that this has >> not changed with IEEE 1800-2005. >> >> At this moment there two positions in a module instantiation where an >> attribute is allowed: on the module instantiation itself (according to >> IEEE 1364-2005 A.1.4): >> >> (* port_discipline="electrical" *) mextram504 >> q1 (node1, node2, node3, node4, (* port_discipline="thermal" *) nodet); >> >> and on the individual ports (according to IEEE 1364-2005 A.4.1): >> >> mextram504 q1 ((* port_discipline="electrical" *) node1, >> (* port_discipline="electrical" *) node2, >> (* port_discipline="electrical" *) node3, >> (* port_discipline="electrical" *) node4, >> (* port_discipline="thermal" *) nodet); >> >> If the first item is not acceptable, the long-term solution would be >> to request an update in IEEE 1364 and IEEE 1800 to allow attribute >> instances also on the module instances in a module instantiation. >> >> Cheers, >> Marq >> >> >> Inactive hide details for "Martin O'Leary" <oleary@cadence.com>"Martin >> O'Leary" <oleary@cadence.com> >> >> >> *"Martin O'Leary" <oleary@cadence.com>* >> >> 05-09-2007 05:42 >> >> >> >> To >> >> "Geoffrey.Coram" <geoffrey.coram@analog.com> >> "Marq Kole" <marq.kole@nxp.com> >> >> cc >> >> "verilog-ams" <verilog-ams@eda-stds.org> >> >> Subject >> >> RE: port_discipline >> >> Classification >> >> >> >> >> >> I also don't think attributes should carry over like this. They are only >> meant to apply to the object they proceed. >> >> However a way to solve this issue is to allow the attribute on the >> instance and on the port names. >> >> The port_discipline attribute before a port binding would apply to that >> port. >> >> The port_discipline attribute before the instance would allow to apply >> to all the ports unless overwritten by another port_discipline attribute >> before a port binding. >> >> Hence for the self heating device you would have; >> >> mextram504 (* port_discipline="electrical" *) q1 ( node1, node2, node3, >> node4, >> (* port_discipline="thermal" *) nodet); >> >> Thanks, >> --Martin >> >> -----Original Message----- >> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On >> Behalf Of Geoffrey.Coram >> Sent: Tuesday, September 04, 2007 5:41 AM >> To: Marq Kole >> Cc: verilog-ams >> Subject: Re: port_discipline >> >> > Another approach would be to have the port discipline of the first >> port > automatically apply to any successive ports, if those ports >> following it > do not have a port_discipline attribute specified. So: >> >> In 1364-2005, does the attribute ever "carry over" in this fashion? >> I suspect not, so I would be disinclined to make the discipline >> attribute special in this way. >> >> -Geoffrey >> >> -- >> This message has been scanned for viruses and dangerous content by >> MailScanner, 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.Received on Mon Sep 10 07:07:05 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 10 2007 - 07:07:22 PDT