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