David Sharrit wrote: > I fail to understand how the present LRM scheme can result in a > connect module above "top". The basic definition of "top" being that > it has no used port connections would seem to clearly rule out such a > possibility. At one time you could not mix analog and digital in the same module so any mixed design there would always be a parent to the port requiring a connect module to be inserted. Since you can now mix stuff within a module there may not be a port as such or a parent. [There was a long argument in earlier times about whether connect modules should be attached to ports or processes, I still maintain the latter is the correct approach since it is based solely on the presence of drivers/contributions/receivers and is independent of the hierarchy.] > One key reason why connect modules need to remain in the parent module > and not the child module would be the built-in primitives. One > couldn't go about inserting connect modules into primitive devices. > And why should user modules be handled differently. Just because something appears to be a child of something else in the hierarchy does not mean that the parent needs to be aware of it. You would want to instantiate connect modules for primitives as their children for the same reasons as other types of modules. > The proposed naming convention still seems ambiguous. It seems one > could easily end up with multiple top.mixed.d2a instances, in the > split mode, simply by having the top.mixed signal drive multiple > modules, each of which needs the connect module named d2a. For a given signal it will only have one a2d and/or d2a in any given instance, so if the signal name is part of path there is no ambiguity - noting that you use the signal name in the module where the connect module is inserted (not the one from the module where the driver, contribution or receiver is). > > It's my understanding that connect modules only apply to port > connections. You seem to be suggesting that they can also somehow > apply to interactions between analog and digital blocks within the > same module. That seems ruled out by the LRM and would require a > whole lot more new definition work, and changes, than just the couple > short paragraphs in this proposed alternative. [As above, it's not really necessary to associate the connect module with a port, the port is only useful as somewhere to hang the discipline/type information. However that is a fairly orthogonal issue I'd be happy to discuss on another thread.] > While I couldn't really follow the argument about back-annotation and > connect power supplies, it does bring up an issue where the LRM does > seem severely lacking. Presently, the whole issue of how to get power > and ground into a connect module seems totally undefined in the LRM, > resulting in vendors having their own proprietary and incompatible > implementations. This then destroys many of the advantages of an > industry standard, at least when it comes to more sophisticated > connect models that attempt to incorporate dynamic power supply > related issues. Those are issues I think we can fix. I would hope that actually addressing issues related to power management will help motivate folks in the SystemVerilog committees to incorporate Verilog-AMS sooner rather than later. Kev. > > David Sharrit > > edaorg@v-ms.com wrote: >> David Sharrit wrote: >>> I don't understand why this change is being proposed and why >>> backward compatibility is being broken. In 8.8.4, the LRM states >>> "The connect module for a port shall be instantiated in the context >>> of the ports upper connection". That would seem to strictly >>> establish the path for the connect module instance. And then the >>> presently defined instance name allows for a clear distinction, >>> especially in the split case, between the numerous instances of the >>> connect module that may be present in that same context. This >>> proposed alternative does not seem to accomplish that. >> Sorry, missed that when I was scanning the LRM. However that brings >> me back to the original motivation i.e. the upper side of the ports >> is the wrong place for the connect module to be instantiated. The >> reason that it is wrong is do with connecting to power supplies (and >> other implicit ports) from within a connect module. Since (digital) >> Verilog doesn't currently have mechanism for describing how to >> connect power supplies, the most likely way it is going to be done is >> by doing an upward hierarchical search from the module that needs >> the connection until you find the appropriate signals. If the connect >> modules for ports on instances at the same level in the hierarchy are >> in the parent rather than being children of the ports' respective >> modules then you run into a problem with back annotation: for digital >> back annotation extra timing delay elements are inserted at the ports >> and (presumably) for analog extra components (wire models and >> parasitics) will be inserted between the ports, so when you do a >> hierarchical search for connections from the connect modules with the >> current scheme you are on the wrong side of the back-annotated elements. >> >> The connect module instance name changes with the proposed scheme >> because the module/instance name is redundant once the connect module >> has been pushed down a level in the hierarchy. >> >> As I said in a previous e-mail you could alias the connect-module so >> that it appears in both places in the hierarchy and mark the old >> behavior as deprecated - so things can be backward compatible. If the >> version 2 of the proposal is accepted then it is extremely unlikely >> that such aliasing would cause any problems since the duplicate >> instance is outside the regular instance hierarchy. >> >> Note: with the old scheme if you had an analog block and a digital >> block in your top module "top" that interacted in a way that required >> a connect module to be inserted the connect module would be above >> "top" in the hierarchy which would make it parentless - which seems >> odd to me. >> >> Kev. >>> >>> David >>> >>> Kevin Cameron wrote: >>>> Martin O'Leary wrote: >>>>> Kevin, >>>>> Does the proposal change anything specified in the existing LRM? >>>>> i.e. is it backwardly compatible? >>>>> Thanks, >>>>> --Martin >>>> Yes, but the current text doesn't specify the path and the name is >>>> over-specified, so backward compatibility might be a moot point. >>>> However... >>>> >>>> I was tempted to add some aliasing so that there would be more than >>>> one way to get to the connect module instance, e.g. if you are >>>> using merged rules then the instance will probably move about, but >>>> it might be useful to be able to get to it from any of the lower >>>> level module instances e.g. if you are in instance top.foo.bar and >>>> have a signal "sig" then for a split insertion the path to the >>>> connect module instance might be: >>>> >>>> top.foo.bar.sig.a2d >>>> >>>> If you swap to merged rules the connect module might migrate up the >>>> hierarchy to (say) foo so it's path might be top.foo.sig2.a2d >>>> (foo.sig2 being connected to bar.sig). If you have a test-bench >>>> relying on the original (split rule) path it would no longer work, >>>> but the simulator could add the path top.foo.bar.sig.a2d as an >>>> alias for top.foo.sig2.a2d (like a file-system soft-link) and then >>>> it would be a valid path. >>>> >>>> Similarly if backward compatibility is required you can add an >>>> alias for the old path. >>>> >>>> Kev. >>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:* owner-verilog-ams@eda.org >>>>> [mailto:owner-verilog-ams@eda.org] *On Behalf Of *Jonathan David >>>>> *Sent:* Thursday, February 01, 2007 1:13 PM >>>>> *To:* Kevin Cameron; Verilog-AMS LRM Reflector >>>>> *Cc:* Kevin Cameron >>>>> *Subject:* Re: Alternative text for 8.8.5: Vesrsion 2 >>>>> >>>>> I'd find that confusing as I don't expect a signal name to be in >>>>> ANYTHINGS hierarchical path.. >>>>> BUT that may ALSO guarantee that there is no name conflict.. >>>>> (which the __ doesn't quite do..) >>>>> >>>>> Jonathan David >>>>> j.david@ieee.org >>>>> jb_david@yahoo.com >>>>> http://ieee-jbdavid.blogspot.com >>>>> Mobile 408 390 2425 >>>>> Work: >>>>> jbdavid@scintera.com >>>>> http://www.scintera.com >>>>> 408 636-2618 >>>>> >>>>> >>>>> ----- Original Message ---- >>>>> From: Kevin Cameron <kevin@sonicsinc.com> >>>>> To: Verilog-AMS LRM Reflector <verilog-ams@eda.org> >>>>> Cc: Kevin Cameron <kevin@sonicsinc.com> >>>>> Sent: Thursday, February 1, 2007 12:55:08 PM >>>>> Subject: Alternative text for 8.8.5: Vesrsion 2 >>>>> >>>>> >>>>> >>>>> Thinking about it I don't like the "__", I'd rather have a ".", >>>>> gives tools the opportunity to let you browse into the signal >>>>> as a >>>>> scope and list what's there. >>>>> >>>>> Alternative text for 8.8.5 (8.8.5.1 stays the same): >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> Instance names for auto-inserted instances >>>>> >>>>> Parameters of auto-inserted connect instances can be set on an >>>>> instance-by-instance basis with the use of the defparam >>>>> statement. >>>>> This requires predictable instance names and instance paths for >>>>> the auto-inserted modules. >>>>> >>>>> In both the merged and split cases the connect module instance is >>>>> located in the nearest parent of the analog or digital blocks >>>>> using the connect module (the location of the contributions, >>>>> drivers or receivers), e.g. in the case where those blocks are in >>>>> one module the connect module instance will be a child of that >>>>> module. In the split case the connect module instance is only >>>>> associated with one block so it is automatically the child of >>>>> that >>>>> block's module. >>>>> >>>>> The instance name of the connect module is made up from the name >>>>> of the signal being connected in the module which is parent to >>>>> the >>>>> connect module instance (which need not be a port), and the name >>>>> of the connect module concatenated with a double dot ".", e.g. >>>>> for >>>>> signal "mixed" in module "top" with a connect module "d2a" >>>>> instantiated in it the connect module path is: >>>>> >>>>> top.mixed.d2a >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> Comments? >>>>> >>>>> Kev. >>>>> >>>>> >>>>> -- 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 Fri Feb 2 13:31:37 2007
This archive was generated by hypermail 2.1.8 : Fri Feb 02 2007 - 13:31:46 PST