RE: [sv-ec] cross scheduling-domain class extension problems

Arturo,

 

I want to address the issue of race conditions by the rules concerning
blocking and non-blocking assignments. This was not part of the original
ballot issue, but since you are tying them together...

 

First, I think we all agree that the rules concerning blocking and
non-blocking assignments between the design and program are there to
enforce a modeling paradigm, and not an issue for implementation. If
that's not the case, then stop here.

 

Second, there are data types that do not allow you to make non-blocking
assignments to them; these include class properties and dynamic arrays.
Since you can't perform non-blocking assignments on these types, the
user must use other mechanisms to prevent races conditions. Also,
designers will want to use sparse arrays to model memories, and a
program block would be unable to initialize a design memory.

 

Third, if a class is defined in the design space, the way the LRM is
current defined, if a program wants to write to that classes properties,
regardless of whether it is instantiated in a program or in the design,
it has to go through a method to do a blocking assignment. This means
that the class writer has to be aware that the program may want to write
to its properties and provide methods to do so. Doing so breaks the
modeling paradigm that the design is not supposed to know about the
program.

 

So, I would propose that the rules in 17.2 be changed to apply only to
static and non-dynamic variables. Perhaps we could do this by modifying
issue 163/mantis  554

 

Dave

 

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Arturo Salz
Sent: Wednesday, April 27, 2005 8:02 PM
To: Vreugdenhil, Gordon; SV_EC List
Subject: [sv-ec] cross scheduling-domain class extension problems

 

Gord,

 

Before this issue becomes more tangled, I want to make sure everyone
understands the problems I have problem with your proposal.

 

I have narrowed my objections to six key issues. The first two are
deviations from traditionally accepted Object-Oriented principles ---
call these first principle objections. The last four are serious
semantical problems with regards to the scheduling semantics that your
proposal creates.

 

1) Different parameters -> different types.

In general, objects of the same class that exhibit different context
behavior represent different types. For example, each version of a C++
templated class or a generic Java class creates its own unique type.
Your proposal violates this principle because it stipulates that the
behavior of a class must change depending on the context in which the
class is extended or instantiated. And, notwithstanding that the classes
have different behavior (i.e., context parameter), your proposal
suggests that all such classes be of the same type.

I believe that the type system becomes compromised when classes with
different context semantics are of the same type. Thus, a program
extension and a module extension of the same schedulefree class should
create two different base types.

 

2) Class modification without override.

In your proposal, the semantics of a schedulefree base class is modified
by extension but without any override. This is a new OOP concept. You
seem to explain that this is similar to a virtual method, but virtual
methods themselves are an overriding mechanism. And, if this were the
case, then what is the difference between regular and virtual methods in
a schedulefree class?

 

3) Static task methods in schedulefree classes are indeterminate.

By definition, a static method must be the same throughout the system,
regardless of how a class is extended. Note how it is an error to even
use the "this" handle in a static method. Since schedulefree classes are
devoid of scheduling semantics, your proposal makes static tasks
indeterminate. I see no possible solution than to outright disallow
static tasks from schedulefree classes. Note that the classes
parameterized by context proposal does not have this problem.

 

4) Static members of schedulefree classes are extremely race prone.

By definition, a static class property must refer to the same physical
variable regardless of class extensions or object instance. When a
schedulefree class is extended in a program context (with Reactive
region scheduling) and a module context (with Active region scheduling),
then objects of either extension will access the same variable, but in
different scheduling regions. This leads to a situation very similar to
the following traditional Verilog problem:

 

    module m( input clk, output a ); 

 

        always @(posedge clk) a = 1;

 

        always @(posedge clk) a <= 0;

 

    endmodule

 

The above code represents poor coding style, but it does illustrates the
very same situation created by static variables in schedulefree classes.
The only difference is the use of the Reactive region instead of the NBA
region. Such variables exhibits both write-write and read-write races.

The solution to this problem may require complex methodology rules, for
which the compiler can offer no help, or perhaps disallow static
variables from schedulefree classes altogether. However, that is not
enough since the same problem reappears when schedulefree tasks are
allowed to access static variables (e.g., in a module, $unit, or
package).

 

5) Uncontrolled access to program / module data.

With the existing language restrictions, it is impossible for
module-resident code to call tasks in programs. This is because the
visibility rules were carefully crafted to avoid this situation.
However, that is no longer true when schedulefree classes are extended
in both programs and modules. Because the base class represents one type
(which is described in point 1), this mechanism allows users to create
heterogeneous collections of Active and Reactive objects. However, it
also opens a back door that allows a module to trivially get a handle to
a program object, and through it direct access to program variables and
tasks.

Access to program tasks (which are intended to execute after the Observe
region) from a module (which are intended to execute before the Observe
region) is a new and very serious situation for which no solution
exists.

 

For starters, we have no semantics for what to do when a module calls a
program task. Should the program task simply execute as part of the
module (Active region) execution, intermingling its execution with that
of the clock and signal propagation of other modules? Or, should the
task (upon entry) delay its execution by posting an event into the
Reactive region? If we allow the former, the task will surely lead to
races and will likely fail. If we choose the latter, then the execution
of a task method depends not only on the type of object, but also on the
context of the caller. This is not just a compiled versus interpreted
code issue; every task has to explicitly check for this, and every
caller has to pass the corresponding information.

Next, what should happen when the program task returns control to the
calling module? Upon the task's return, the region being processed is
the Reactive region. So now, the remaining module code will execute
after the Observe region has been processed. Clearly, turning back time
is impossible, but what restrictions should be applied to that code?
Should it be disallowed from triggering clocks?

Consider, for example, what happens when a program task relies on the
disposition of an assertion to diagnose a problem or to trigger a
coverage point. In either of these cases, the task will likely
misbehave. I firmly believe that there are no "correct" semantics that
we could associate with such a task call; the state becomes inconsistent
either in the caller's context or the in method's context. Finally, the
rules whereby users could avoid such problems are extremely complex,
especially with data structures of such heterogeneous handles more
complex than simple lists. It appears that the only real simple solution
is to limit their use to very simple "pure" classes, which makes the
entire proposal mute.

 

This fifth point is perhaps the most troubling part of the proposal.
During the meeting I expressed deep concern about the proposal's
requirement to create these heterogeneous class handles. I believe they
have the ability to severely undermine the well ordered behavior of the
scheduling semantics.

 

6) Additional semantics are not addressed.

Program tasks and module tasks do not only differ in the region in which
they post events. There also exist a number of semantic restrictions
associated with program tasks. I understand that your proposal wants to
treat these two as separate issues, but the two are intimately related.
The restrictions on program tasks (and functions ) are an integral part
of the race safety mechanism associated with the Reactive region
scheduling, but I haven't see how you intend to make these semantic
checks compatible with your proposal and it's imperative that this be
addressed in order for the other mechanism to be considered. 

 

    Arturo