Re: V-AMS DevModeling meeting April 6, new proposal doc

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>I didn't want to use "ref", I proposed/voted for just using
>>C's `*' but that was rejected. So I agree with your concern.
>>However, two mechanisms for doing exactly the same thing are
>>unlikely to be allowed later when it comes to reconciling the
>>languages, so you might as well bite that bullet now.
>>
>>
>
>I think you're missing the point. SV allows function arguments
>to be inout or output (as well as ref and input). We're
>proposing to allow inout and output in Verilog-AMS. That's it.
>We're not adding anything that isn't already there in SV.
>It's simply a note to the wise that, from a simulation
>standpoint on the analog side, these two things are equivalent.
>These things aren't equivalent on the digital side (because
>of blocking etc) so the distinction will have to remain in SV.
>
>
Inout means "copy-in copy-out" - its a lot more inefficient than pass by
reference.

>>You may want to check for no external drivers/contributions/
>>receivers rather than "no connection", since the user may put
>>a wrapper round a model which connects the port but then the
>>wrapper port may not be connected. Also, hierarchical references
>>connect without ports.
>>
>>
>
>Your first point is interesting; however, what happens if you
>have two devices with optional terminals which are connected
>together? Do both of them believe the terminal is driven,
>or both believe it is not?
>
>
I would count optional terminals as connected external to the instance
itself - otherwise
bad things could happen :-)

>>Parsers are the easy part of building (Verilog) HDL tools,
>>there are even some open-source Verilog tools that'll do
>>most of that for you, so I don't think that's an obstacle
>>(at least for the in-house folk).
>>
>>
>
>I wasn't saying the parser was a problem. I was saying that
>the simulator itself does not have constructs to handle a
>system-level HDL, so even if I could parse it, I'd have
>nothing to hook it up to.
>
>
I was only suggesting adopting bits of syntax that would be useful. Many
things
in Verilog-A(MS) may also be useful in SV, so I'd like to avoid having
syntax/
semantics that depend on context (I like polymorphic code), and I'd
prefer not
to have too many ways to do the same thing.

>>Cadence & Synopsys will be integrating their Verilog-AMS
>>with SystemVerilog and are likely to change stuff they
>>don't like in the process (since they've got more clout
>>and resource), so my advice is to avoid conflict and go
>>with SV syntax now. NB: the number of people working on the
>>SV committees (& IEEE) far out-weighs the number working on
>>Verilog-A(MS).
>>
>>
>
>Well, it would sure be nice to have some of the SV people
>join the AMS work -- Sri has complained for a while that
>his committee doesn't have the familiarity with SV.
>
>-Geoffrey
>
Maybe Motorola will let Sri build a SystemVerilog-AMS now that the
economy is
picking up and their stock price is on the way up :-)

Kev.

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862