Re: Alternative text for 8.8.5: Vesrsion 2

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.

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.