RE: About DUT error action blocks

["Yaron Kashai" <yaron@cadence.com>]

Hi Mark,

It seems to me that you are looking for a standard
that would reflect the exact state of the language
today. Standards are slow moving - even if we manage
to do this, by the time our standard is out there 
would be extensions. By the time we'll make a revision
there would be more extensions...

This does not mean a standard is pointless: it captures
the vast majority of the language and provides a basis
for further evolution. Additions are easily captured in
terms of the language already defined (as you point out
below).

It's going to be way easier for a hypothetical vendor
to create a superset of a well defined standard, compared
to starting with nothing.

Recognizing that this is the general case, the question is
reduced to whether you see special importance to updating
the DUT_error construct? This can obviously be done and 
we chose not to do so simply to maintain consistency across
the language front.

BLTF team: any opinions on this extension?

Cheers,
-- yaron

>-----Original Message-----
>From: mastrick@cisco.com 
>Sent: Monday, August 08, 2005 7:11 AM
>To: Yaron Kashai
>Cc: 1647-bltf@ieee1647.org
>Subject: RE: About DUT error action blocks
>
>Yaron,
>
>For current e coders, the IEEE standard is only marginally 
>useful, if at
>all, if tools built to it cannot parse code being written today.  Since
>the dut_error action block already exists, not mentioning it to the
>extent of it being an option in the syntax means that there is 
>some code
>already that is not compatible.  The more instances of this
>incompatibility that there are, the less useful having a standard is.
>Since the hypothetical tool that uses a parser based on the 
>standard may
>not even require knowing what is in the action block, if its 
>parser just
>accepted the contents as comments, the standard could still be 
>useful in
>that case.  
>
>In general, an action block is pretty well defined (see the "on" or
>"exec" blocks), so what is the difficulty in including it for
>dut_error() in the same way?
>
>Mark 
>
>-----Original Message-----
>From: Yaron Kashai [mailto:yaron@cadence.com] 
>Sent: Friday, August 05, 2005 1:56 PM
>To: Mark Strickland (mastrick)
>Cc: 1647-bltf@ieee1647.org
>Subject: About DUT error action blocks
>
>
>Hi Mark,
>
>Regarding issue 517, you write:
>"Since dut_error action blocks are currently supported by Specman, the
>LRM should at least allow them, even if it says details will follow in
>the next revision.  Otherwise, another parser built to the LRM 
>will fail
>my existing code."
> 
>I tend to disagree: DUT_error with action block is a pure extension to
>the base language (the version we started with). The LRM in 
>it's current
>form doesn't rule it out. It simply doesn't mention it. 
>
>The argument that a parser built based on the spec won't parse 
>your code
>is correct - that will be the case for any extension of the language
>current and future. By nature, the standard will lag behind the current
>"state of the art".
>
>The standard should not rule out such extensions - this is the problem
>we are facing with the pairwise binding. But it is fine for 
>the standard
>not to mention a feature. The implementer of the new parser 
>will be able
>to go beyond the standard definition, provide DUT_error constructs with
>action blocks and still REMAIN COMPLIANT.
>
>Another practical issue is that the standard needs to be self 
>contained.
>It can't talk about future extensions, nor leave around syntax without
>providing matching semantics. 
>
>With that I hope you will agree to dismiss the issue. 
>
>Cheers,
>-- yaron
>
>