RE: [sv-cc] uploaded proposals for 465 and 528

It would return a frame which parent would be a process.
 

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim
Vellenga
Sent: Thursday, April 28, 2005 9:03 AM
To: Francoise Martinolle
Cc: sv-cc@eda.org
Subject: RE: [sv-cc] uploaded proposals for 465 and 528

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.
] ]  
] ] 
] 
] 
] 
]