Sorry folks, lots of confusion yesterday, as I was away from my primary keyboard
most of the day,
So please allow me to clarify:
In the discussion for evaluating whether a pin was driven, there was a
suggesting for an elaboration time function (llike $connected) to report if the
pin was driven or not, and I was suggesting that the "driven" status is
something that could change thru the run time, this was the discussion for the
PORT of the chip, not "a node" - so I wasn't talking about "a floating node",
but rather a floating external connection, since with a PlugNPlay type system,
you would want to validate thru simulation that you can make and break those
connections and the SW and HW do all the right things as that happen, so I would
much rather have run time system function that could tell me if the pin has a
connection to anything at this point in time.
(ie a wtranif1(pin, somethingelse, exprs_with_0_value) would NOT find a
connection).
note: here I am postulating a NEW type of tranif1 that doesn't care what kind of
signal is being connected.. it either IS or ISN'T connected at any point in
time.. the signals on either side could be wires carrying logics, real_numbers
(or electricals in an AMS sim). this is something that would be nice.
and one more comment, I believe that UVM1.0 has a "build" phase in the
simulation -- which happens well after the simulator elaboration happens.. so I
think those of us on the AMS committee should start keeping in mind all these
"new" (to us) steps that are happening in typical verification simulations.
sorry to have been too cryptic yesterday, hopefully this was not too much of an
over-compensation the other way,
Jonathan David
Jonathan David
j.david@ieee.org
jb_david@yahoo.com
http://ieee-jbdavid.blogspot.com
Mobile 408 390 2425
________________________________
From: Kevin Cameron <edaorg@v-ms.com>
To: Dave Miller <David.L.Miller@freescale.com>
Cc: Verilog-AMS LRM Committee <verilog-ams@eda.org>
Sent: Fri, February 18, 2011 11:18:39 AM
Subject: Re: Verilog-AMS Committee Meeting Minutes - 17th Feb 2011
On 02/18/2011 09:29 AM, Dave Miller wrote:
> ..
> The next item that was discussed was the BNF, do we want to have an appendix
>that is just the AMS changes to the P1800 or do we want to support a single
>merged BNF? Still undecided, but feel the most useful option is a single merged
>BNF. Yes, it does mean we need to keep it up to date with changes in the parent
>P1800 BNF, but changes in the BNF are not quite as drastic as the potential
>document changes between revisions.
As I've said before: the BNF is usually the last thing you need to worry about,
nothing should be gated on BNF analysis at this point. By the time the AMS stuff
gets incorporated the BNF for the rest of SV will have changed, the semantics of
object interaction are more important.
> Dave asked a question related to the request by Jonathan regarding detecting of
>floating node conditions during run time.
>
> Geoffrey explained that they are not ideal floating nodes, but situations where
>for example, a MOS device is turned off. The node may exhibit a very tiny
>conductance and be very loosely controlled. It is these high impedance nodes
>that people are interested in detecting. If the tools could detect these
>conditions, it would be very useful.
That sounds like the kind of thing you want to put in the models as an
assertion. You might want to add an assertion phase where you can poke the
matrix and see what the node impedance is after it has been solved. I would pass
that one on to the analog assertions committee.
Kev.
-- This message has been scanned for viruses and dangerous content by MailScanner, 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 18 11:57:13 2011
This archive was generated by hypermail 2.1.8 : Fri Feb 18 2011 - 11:57:17 PST