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. * >>> >> >> > -- 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.Received on Thu Feb 1 21:55:36 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 21:56:06 PST