RE: Recoverable Errors

Hi John,

> OK I'm cleared up now on what you were trying to convey and
> I think we're in basic agreement.

Good :-)

I have some responses to your comments below.

> OK, I guess we're getting subtle points now but let's
> consider the SceMi::BindMessageInPort() call for example.

> True there are two kinds of recoverrable errors here, namely,
> no matching port was found because either 1. the transactor
> name was not present, or, 2. the port name was not present.

> But from a code flow point of view the application would
> probably do only one thing in reaction to either of these
> errors. I.e. either error will cause the code to do what it
> does when the matching port is not found for whichever of
> the two reasons.

I agree this is subtle and we are probably ahead of our time
in the sophistication of SCE-MI IP, but I can envision IP code
that could really take advantage of knowing the distinction
of which recoverable error was caused. For instance, I can
envision a family of transactors/BFMs that are related but
have slightly different combinations of ports. If they are
sufficiently related they can be served by the same C/C++
SW-side code, that is, substantially the same with some
branches relative to what ports were found. So knowing that
the recoverable error is `port not found' is helpful to code
such as this as it would use it to find out what sub-flavor
the particular transactor it's communicating with is. In
this case, `tranactor not found' is a more serious error,
that could be used by the software layer to convey an error
to a higher layer.

On the other hand, `transactor not found' would be an error
useful to distinguish families of testbenches at the layer
of the SW-side that configures the SW-side of the testbench.

True, you can do both of the above with a collapsed recoverable
error indication, but it becomes more cumbersome and the code
can do less on its own. I think the latter becomes more
important if we want to promote SCE-MI based IP versus standalone
monolithic SCE-MI applications.

> If the application wants to convey more specific information
> (i.e. which of the 2 reasons for the error) to
> the user, that will be clearly spelled out in the message
> embedded in the SceMiEC.

This is OK for reporting to the user but not useful to the code
as the error codes and messages are implementation defined and
likely to change from release to release.

I'd like to explore the question of whether we should collapse
recoverable error codes or not at the next meeting.

> My assertion is that if the code had properly called NumberOfObjects()
> before calling this it would have discovered that there were 0
> objects of the given kind and should not have bothered to call this
> call in the first place. So if it does, it should be considered fatal.

Even given that, I still prefer the recoverable error approach
especially if I'm given an indication of which recoverable error
it is. It is just more convenient to just call the attribute
lookup function than first have to call NumberOfObjects() and
then divert depending on the result. But I can go either way
on this one.

> Similarly, NumberOfObjects() returns a proper and valid range for
> indexing so there's no excuse for violating that, therefore index
> out of bounds should be considered fatal.

Same comment as above.

> Finally, for any given object kind there's a fixed and clearly
> specified set of attributes that go with it.

No, I think this is incorret. There is a fixed *minimum* set
of attributes, but the spec allows the implementation to add
attributes and objects of its own. It is easy to envision
even portable SCE-MI code accessing implementation specific
attributes. For example, different implementations might use
such attributes to store information that allows the application
to fine tune its performance or change aspects of how the
implementation handles messages. So highly tuned SCE-MI IP code
might want to probe for different attributes to find out if it
is running under a particular implementation.

Another aspect is that the current defined standard set of
attributes may be augmented in the future and some users may
want to write code that can run on several versions of SCE-MI.

If all you get is a fatal error on looking up a non-existent
attribute, then the application code has no way of telling
what the error really was. Ok, it could just assume that
it was just a benign fatal error (isn't that an oxymoron, anyway?)
such as attribute not found and continue, but then if it was
really a true fatal error it is likely to get more and perhaps
the application will segfault eventually without giving the
user a good indication of what went wrong.

What do you think?

Thanks,
Per
Received on Mon Jun 28 07:55:31 2004