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. 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. 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. 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. 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. 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 11:20:44 2007
This archive was generated by hypermail 2.1.8 : Fri Feb 02 2007 - 11:20:47 PST