RE: [sv-ac] call to vote on Mantis 1674

If you look at the VPI object model, there's a regular way of moving
from one object to any other object through a limited set of operations.
Then from any object, there's a regular way of querying or setting
information about that object. With the PLI, there were separate tasks
to do individual operations. For example, there was one function to get
the value of a signal, another to get the value of a task argument, and
another to get the value of a parameter.

I'm not suggesting that the solution has to be introspection, but that
you take a global look at all the features that need to be added and see
if there are better language based solutions. It looks like you are
trying to get access to inferred signals from within a property and
inferred signals from the context where a property has been
instantiated. Then I see the three different kinds of signals that are
being inferenced. What if you decide you need to know the global
defaults as well? Then you have to add three more system functions.

Mantis 1682 is probably a poster example of the problem I see. A year
from now, who outside the sv-ac is going to remember the difference
between $rose, $rose_i, $rising_i (I don't remember if $posedge was
added elsewhere). Come up with a single definition of
rising/falling/changing, then come up with definitions for past, current
and future, then try to come up with syntax that blends the two concepts
together without creating unique identifiers with each combination.

Dave
 

> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Friday, April 27, 2007 1:39 PM
> To: Rich, Dave; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] call to vote on Mantis 1674
> 
> Hi Dave,
> 
> is it not, though, that the user must have means of specifying where
the
> inference should be made and where not? How would introspection help
> that?
> 
> Thanks,
> ed
> 
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of Rich, Dave
> > Sent: Friday, April 27, 2007 4:30 PM
> > To: sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] call to vote on Mantis 1674
> >
> > Ed,
> >
> > My problem with this proposal is that it needs a more general
language
> > based way to solving the problem. Synthesis tools will certainly be
> > interesting in utilizing inferred clocks, resets and enables.
> >
> > The sv-ac has been adding what looks like system functions
> > all over the
> > place in a relatively ad-hoc manner, and the list is getting
> > relatively
> > large. This same thing that happened to the PLI 1.0 as the number of
> > routines grew. They replaced it with a more OO-like VPI when
> > it started
> > to become unmanageable.
> >
> > My suggestion is to start looking at other languages with
> > introspection
> > (Python) and coming up with more regular ways querying context
> > information.
> >
> > Dave
> >
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org]
> > On
> > > Behalf Of Eduard Cerny
> > > Sent: Friday, April 27, 2007 10:44 AM
> > > To: Kulshrestha, Manisha; john.havlicek@freescale.com;
> > sv-ac@server.eda-
> > > stds.org
> > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > >
> > > I think that there is a real need to be able t specify such
default
> > > arguments, otherwsie properties are not reusable in different
> > contexts.
> > > Therefore, would you have a counterproposal? Or what you feel is
not
> > > intuitive?
> > >
> > > Regards,
> > > ed
> > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > > > Behalf Of Kulshrestha, Manisha
> > > > Sent: Friday, April 27, 2007 1:36 PM
> > > > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > >
> > > > I vote no on 1674. I am not convinced that the current way to
> > replace
> > > > default arguments with $inferred.. is the right way to do
> > this. This
> > > > makes it unnecessarily complicated and it is not very intuitive.
> > > >
> > > > Thanks.
> > > > Manisha
> > > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@server.eda.org
> > > > [mailto:owner-sv-ac@server.eda.org] On
> > > > Behalf Of John Havlicek
> > > > Sent: Wednesday, April 18, 2007 4:20 AM
> > > > To: sv-ac@server.eda-stds.org
> > > > Subject: [sv-ac] call to vote on Mantis 1674
> > > >
> > > > All:
> > > >
> > > > This is the call to vote on the proposal for Mantis 1674.
> > > >
> > > > As discussed in our meeting, this vote runs longer than
> > > > the usual week because we have so many e-mail ballots
> > > > running concurrently.
> > > >
> > > > Please vote if you are eligible.  See the details below.
> > > >
> > > > J.H.
> > > >
> > > > Ballot on Mantis 1674
> > > >
> > > > - Called on 2007-04-18, final ballots due by 23:59 PDT on
> > 2007-04-30.
> > > >
> > > >  v[xxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Freescale)
> > > >  v[xxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)
> > > >  n[---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
> > > >  v[x-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
> > > >  t[xxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
> > > >  v[xxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
> > > >  v[xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
> > > >  n[---xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
> > > >  n[x.....................] Joseph Lu (Altera)
> > > >  n[x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> > > >  v[xxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
> > > >  v[xx-x..................] Erik Seligman (Intel)
> > > >  n[-----xxxx-xx----------] Tej Singh (Mentor Graphics)
> > > >  v[xxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> > > >  v[xxxxxxx...............] Tom Thatcher (Sun Microsystems)
> > > >    |---------------------- attendance on 2007-04-17
> > > >  |------------------------ voting eligibility for this ballot
> > > > |------------------------- email ballots received
> > > >
> > > >
> > > > 	Legend:
> > > > 		x = attended
> > > > 		- = missed
> > > > 		r = represented
> > > > 		. = not yet a member
> > > > 		v = valid voter (2 out of last 3)
> > > > 		n = not valid voter
> > > >                 t = chair eligible to vote only to make or break
a
> > tie
> > > >
> > > > --
> > > > 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.
> > > >
> > > >
> > > >
> > >
> > > --
> > > 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.
> >
> >
> >

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