Francoise, I see that in your proposals vpiWaitingProcesses returns both frames and processes. What happens if a process contains automatic variables? Which kind of object should the iteration return? Regards, Jim Vellenga --------------------------------------------------------- James H. Vellenga 978-262-6381 Engineering Director (FAX) 978-262-6636 Cadence Design Systems, Inc. vellenga@cadence.com 270 Billerica Rd Chelmsford, MA 01824-4179 "We all work with partial information." ---------------------------------------------------------- ] -----Original Message----- ] From: Francoise Martinolle ] Sent: Wednesday, April 27, 2005 11:12 PM ] To: Jim Vellenga; Francoise Martinolle ] Cc: sv-cc@eda.org ] Subject: RE: [sv-cc] uploaded proposals for 465 and 528 ] ] Here is what I understand: ] ] A frame corresponds to a "stack frame", it comes into ] existence whenever ] automatic ] declarations need to exist. A frame exists for any automatic task or ] function or procedural ] scope containing automatic variables. A stack of frames can ] exist, each one ] linked to its parent ] when there are recursive task calls or procedural scopes ] containing other ] procedural scopes ] which define new automatics etc... ] A thread corresponds to what systemVerilog defines to be a ] thread. A thread ] has ] typically a corresponding frame if it has automatic ] variables. If a thread ] forks off other threads, ] each new thread may have its own frame. ] From a frame you can access the automatic variables, that is the whole ] purpose of a frame. ] The only difference with 1364 frame is that SV procedural ] scopes can create ] frames. ] ] ] With that said, I think that the vpiWaitingProcesses ] iteration from an event ] handle ] is incorrect, it should return processes and frames or perhaps just ] processes at a higher ] level of granularity. ] ] Francoise ] ' ] ] ] -----Original Message----- ] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On ] Behalf Of Jim ] Vellenga ] Sent: Thursday, April 14, 2005 11:21 AM ] To: Francoise Martinolle ] Cc: sv-cc@eda.org ] Subject: RE: [sv-cc] uploaded proposals for 465 and 528 ] ] My problem is that I still don't really know what a frame is. ] ] According to our current VPI diagrams, you can get to a frame from ] ] -- a named event (vpiWaitingProcesses iteration) ] ] -- a thread (one-to-one) ] ] -- another frame (parent/child) ] ] -- a class var (vpiWaitingProcesses iteration) ] ] But that in itself does not tell me what frame is. ] ] The non-VPI parts of the 1800 LRM talk about threads ] (10.7) but not about frames. A thread is either ] ] -- an initial statement ] ] -- an always statement ] ] -- a parallel statement in one of the fork/join constructs ] ] -- a dynamic process, or ] ] -- a continuous assignment ] ] So can we tell what a frame is by comparing it to the ] corresponding thread? ] ] Our diagrams show a one-to-one relationship, both ways, ] between threads and ] frames. I think that that must mean (zero or one)-to-(zero-or-one), ] actually. For example, the LRM definition of a thread ] doesn't mention a ] task call or function call, while a frame can represent each ] separate task ] or function call, especially if the calls are recursive. So ] there is not a ] true mathematical one-to-one correspondence between frames ] and threads. ] ] OK, so lets look at the diagram for frames. Can we use it to find the ] process that a frame corresponds to? ] If a frame represents the following always statement: ] ] always @trig rega = regb; ] ] where trig is a named event, then the statement represents a ] process waiting ] on @trig. ] How does one find the always statement associated with the frame? An ] unnamed always statement without a "begin" in it is not a scope. ] ] Those are some of the problems I've run across so far. ] ] It looks to me like we need a clear statement of what a frame ] is and what it ] corresponds to in the SystemVerilog language. Is it dynamic ] -- i.e., can it ] disappear -- and under what circumstances? Since the rest of the LRM ] doesn't discuss frames, we need to define them much more ] clearly in our ] section. ] ] Regards, ] Jim Vellenga ] ] --------------------------------------------------------- ] James H. Vellenga 978-262-6381 ] Engineering Director (FAX) 978-262-6636 ] Cadence Design Systems, Inc. vellenga@cadence.com ] 270 Billerica Rd ] Chelmsford, MA 01824-4179 ] "We all work with partial information." ] ---------------------------------------------------------- ] ] ] ] ] -----Original Message----- ] ] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On ] ] Behalf Of Francoise Martinolle ] ] Sent: Thursday, April 14, 2005 12:08 AM ] ] To: sv-cc@eda.org ] ] Subject: [sv-cc] uploaded proposals for 465 and 528 ] ] ] ] 465: better description of vpiWaitingProcesses ] ] ] ] 528: fixes to the classes information model. ] ] ] ] ] ] ] ]Received on Thu Apr 28 06:03:34 2005
This archive was generated by hypermail 2.1.8 : Thu Apr 28 2005 - 06:04:38 PDT