Re: Info reporting in SCE-MI

Shabtay,

A bit overdue but here are some reponses to your issues.

Shabtay Matalon wrote:
>
> John,
>
> Thanks for the response. Please see my notes interspersed.
>
> Shabtay
>
> >
> > The reason we support the non-NULL pointer option being passed to the
> > call is to support legacy C programming style where every call returns
> > its status and it is up to the calling code to deal with errors on a
> call
> > by call basis. Traditional C APIs, such as many Unix API calls, tend to
> > pass an error status as the return of every call.
> >
> > Given that such archaic error handling tends to have been replaced
> > with more modern error handlers and exception catching/throwing
> > mechanisms, use of NULL pointers on each SCE-MI call is by far the more
> > recommended way of doing things.
> >
> > However, the feeling was that there may be old-style C program
> > applications
> > that may wish for statuses to be returned on each call and do proper
> > error abort handling after the call returns in that traditional way.
> > That is why we added support for this to the specification.
> [Shabtay] Ahhhaa. I new there might be a reason. This makes sense.
> >
> > As for info messages, we felt that an info message handler was a cleaner
> > way to handle them since, unlike abort handling of fatal errors, info
> > messages should not generally affect the flow of execution after call
> > returns.
> [Shabtay] While the SCE-MI spec indicates that EscMiErrors should only
> support irrecoverable errors, I haven't seen in the spec a requirement
> that info messages would not cause an abort. I believe that this is left
> to the application which may result that one implementation behaving
> differently than others, all being scemi compliant.

johnS:
This is most likely a matter of clarification. In intent of
an info message is that it is a warning or purely informational
and should not have the effect of aborting a simulation.

I would suggest the following re-wording after this paragraph:

Existing paragraph in section 5.3.2:

"This method registers an optional info handler with the SCE-MI
that is called when a warning or informational
status message occurs."

Added immediately after:

"This method must only be used for message reporting or logging
purposes and must not abort the simulation. Only SceMiEC error
handlers are reserved for that purpose."

>
> A second order of magnitude issue is that categorization of what is
> considered a SceMiError (aka fatal error) and what is considered Info,
> warning and NonFatal error is also left to the implementation.

johnS:
I think the combination of my added paragraph above combined with
the last paragraph in the section should make these clear. This
last paragraph states,

"An additional category, called SceMiNonFatalError, can be used to
log all error conditions leading up to a fatal error. The final
fatal error message shall always be logged using a SceMiEC structure
and SceMiErrorHandler function so an abort sequence is properly handled
(see 5.3.2.1). In addition, the info message can optionally be tagged
with a unique identifying integer specified in the Id field."

Perhaps we can also add something to section 5.3.2.1 that states
that is expected that user defined SceMiEC error handlers or
user level code reacting to a returned SceMiEC status indicating
a fatal error are expected to initiate an abort operation in
a manner that is properly suited to the application.

>
> If agreed that the first topic is a loophole, maybe it should be
> addressed by more precise language in the section 5.3.2.2 section of the
> SCE-MI spec.
>
> As to the second issue, I think that this deserves thought if the spec
> needs to be tightened. It may well be good enough to leave it to each
> implementation granted that the affect on the flow of execution after
> call returns is not affected.
>
> What do you think?
> >
> > -- johnS
> >
> > >
> > > Thanks,
> > >
> > > Shabtay
> > >
> > >
> > > -------------------------------------
> > >
> > > Shabtay Matalon
> > > Solution Architect
> > > Solutions R&D, SFV
> > > Phone: (408) 428 5081
> > > email: shabtay@cadence.com
> > >
> > >
> > >
> >
> >
> > --
> >
> > This email may contain material that is confidential, privileged
> > and/or attorney work product for the sole use of the intended
> > recipient. Any review, reliance or distribution by others or
> > forwarding without express permission /\
> > is strictly prohibited. If you are /\ | \
> > not the intended recipient please | \ / |
> > contact the sender and delete / \ \
> > all copies. /\_/ K2 \_ \_
> > ______________________________/\/ \ \
> > John Stickley \ \ \
> > Principal Engineer \ \________________
> > Mentor Graphics - MED \_
> > 17 E. Cedar Place \ john_stickley@mentor.com
> > Ramsey, NJ 07446 \ Phone: (201) 818-2585
> > ________________________________________________________________
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________