Mike, Mantis item 890 is where the final proposal will end up. The proposals that are there right now, are old and do not reflect the discussions and preliminary agreements reached in the face to face meeting. The approved minutes from the face to face can be found here. http://www.eda-stds.org/sv-ec/Minutes/SV-EC_f2f_Meeting_November_6_2006_Notes.txt Neil Michael Burns wrote On 11/21/06 12:44,: > So, it sounds like there is not yet unanimity in the committee. Is there a > Mantis for this issue? A working proposal? > > Thanks, > Mike > > Steven Sharp wrote: > >>>From: "Arturo Salz" <Arturo.Salz@synopsys.com> >> >>>At the recent face2face meeting we discussed and have a preliminary >>>agreement that the scheduling should be based on the process call graph >>>rather than where the class is defined or the object is instantiated. >> >>I was not at the face2face, and I disagree rather strongly with this >>idea. A subroutine is an encapsulation of behavior, which should be >>independent of where it is called from. >> >>This idea of using the process call graph also naively assumes pure SV, >>and is not easily extensible to mixed-language situations. I have >>recently heard of proposals (from SCEMI?) to allow calling exported >>DPI tasks from arbitrary places such as SystemC threads. Practical >>cross-language calls rely on encapsulation of the behavior of the >>subroutine, so they have well-defined behavior no matter where they >>are called from. >> >> >> >>>This is different from the way the 1800-2005 LRM defines scheduling, but >>>it does resolve a number of ambiguities and outstanding issues. >> >>And creates others. >> >> >> >>>As for you last question, if the class is instantiated in a module and >>>the method is called from a program, the method call would indeed work >>>just like calling module tasks or functions from the program without >>>regard on whether the class properties are module or program variables. >> >>Agreed. Except that I don't think you can really say that the class >>properties are program variables. The handle used to access them may >>be a program variable, but that does not make the properties themselves >>program variables. >> >>Steven Sharp >>sharp@cadence.com >> > >Received on Tue Nov 21 14:56:45 2006
This archive was generated by hypermail 2.1.8 : Tue Nov 21 2006 - 14:56:52 PST