Re: Expressions as part of port connections in module instantiations

In the original design objectives it is stated that we should allow as
much plug-and-play as possible, I.e. if "ch1(V(a))" is allowed in a pure
analog design it should be allowed in mixed-signal design too. You might
want to disallow sensitivity (assign/@), but that's really a separate
issue. My preference  is that plug-and-play should work and therefore
the assign/@ fire at acceptance rather than being disallowed or ignored.

Kev.

David Miller wrote:
> Well, not sure we should do that. I don't think we should introduce
> exceptions into the language depending on the type of instance that is
> being instantiated. Especially since people might use this for test
> benches and Verilog-AMS monitors, etc.
> I think maybe we need to take a look at chapter 7 - especially 7.3 for
> the next revision. It might need some more work.
>
> For example, 7.3.6.4 states that only analog variables that are
> assigned within analog event statements can be used in continuous
> assignments, meaning:
>   assign win = V(a);
>
> is disallowed as per the language. If we are disallowing that, then it
> is contradictory to then allow:
>
>   child ch1(V(a));
>
> where port of child is a wreal. We can't really have one and not the
> other.
> This problem is not just limited to any analog assertions work.
>
> Cheers...
> Dave
>
>
> Jonathan David wrote:
>> So this type of connection would only be allowed to verification
>> instances - not design instances (modules)?
>> jonathan
>>
>> -----Original Message-----
>> From: Havlicek John-R8AAAU <john.havlicek@freescale.com>
>> Sent: Friday, May 08, 2009 5:16 AM
>> To: Jonathan David <jb_david@yahoo.com>; Kevin Cameron
>> <edaorg@v-ms.com>; Miller Dave-A17239 <david.l.miller@freescale.com>
>> Cc: Verilog-AMS LRM Committee <verilog-ams@eda.org>
>> Subject: RE: Expressions as part of port connections in module
>> instantiations
>>
>> Hi Jonathan:
>>
>> A driving motivation for this capability is to be able to create AMS
>> assertions (in a suitable extension of SVA) within an appropriate
>> container (e.g., a module or a SystemVerilog checker) and hook the
>> assertions up to the various AMS data that they need to observe.  The
>> instance could be an instance of that container.
>>
>> J.H.
>>
>> (not sure if this will go to the verilog-ams reflector ...)
>> -----Original Message-----
>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>> Behalf Of Jonathan David
>> Sent: Friday, May 08, 2009 2:02 AM
>> To: Kevin Cameron; Miller Dave-A17239
>> Cc: Verilog-AMS LRM Committee
>> Subject: Re: Expressions as part of port connections in module
>> instantiations
>>
>>
>> Wow.. so not instead of the ports connecting to Nets (like pin
>> connect to
>> wires) you are now connecting the pin to the color(voltage) of the wire?
>>
>>
>> of course I might want to do that for simulation.. but I might also want
>> to connect to a different representation of the subblock that should
>> connect to the whole wire? After all this isnt VHDL.. do we want the
>> instantiation to vary
>> depending on the represenation underneath?
>>
>>  Jonathan David
>> j.david@ieee.org
>> jb_david@yahoo.com
>> http://ieee-jbdavid.blogspot.com
>> Mobile 408 390 2425
>>
>>
>>
>> ----- Original Message ----
>> From: Kevin Cameron <edaorg@v-ms.com>
>> To: David Miller <David.L.Miller@freescale.com>
>> Cc: Verilog-AMS LRM Committee <verilog-ams@eda.org>
>> Sent: Thursday, May 7, 2009 6:36:34 PM
>> Subject: Re: Expressions as part of port connections in module
>> instantiations
>>
>> [Previous reply didn't make it to the reflector]
>>
>> My question is what's the semantic difference between
>>
>>     child ch1(a)
>>
>> and
>>
>>     child ch1(V(a))
>>
>> - and I would say that the latter is a signal-flow connection of the
>> voltage of node 'a' (a PWL real value), as such it does not require an
>> A2D. Any digital process sensitive to the port in ch1 (assign/@) gets an
>> event at acceptance if V(a) changes.
>>
>> Seems like a reasonable thing to want to do
>>
>> [The entire original message is not included]
>>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.