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

Hello Rich,

good point even if the solution is not obvious. Still, perhaps something
could be done w/o breaking backward compatibility in the case of 1682:

For example, $past is currently defined as:

$past( expression1 [, number_of_ticks] [, expression2] [,
clocking_event])

If we allow number_of_ticks to take values in [-1:$] then -1 could
indicate next clock tick, i.e., future value (negative past == future).
To indicate that global clock should be used, use the name of the global
clocking declaration for the clocking event. The problem with this is
that in the case the future value should be used, the specification
becomes a bit long because both the ticks and the clock must be
specified. On the other hand, compared to the regular use of $past there
will be relatively few such uses and in more specialized situations. 

Dmitry, would something like this be acceptable?

ed


> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
> Sent: Sunday, April 29, 2007 10:42 AM
> To: Eduard Cerny; sv-ac@eda-stds.org
> Subject: 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.