Could we add another argument to distinguish it? ed > -----Original Message----- > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] > Sent: Monday, April 30, 2007 12:14 PM > To: Eduard Cerny; Rich, Dave; sv-ac@eda-stds.org > Subject: RE: [sv-ac] call to vote on Mantis 1674 > > Hi Ed, Dave, > > But how we define $rising_i, $changing_i, etc. in this case? > > Thanks, > Dmitry > > -----Original Message----- > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] On > Behalf Of Eduard Cerny > Sent: Monday, April 30, 2007 3:22 PM > To: Rich, Dave; Eduard Cerny; sv-ac@server.eda-stds.org > Subject: 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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Apr 30 09:40:36 2007
This archive was generated by hypermail 2.1.8 : Mon Apr 30 2007 - 09:40:48 PDT