Johan,
| > why don't we add an alternative, synchronous version of each operator,
| > for symmetry? The answer is that the @ operator is defined to provide
| > an easy way to clock properties, so it is not necessary to have both
| > an asynchronous and a synchronous version of each operator. Why then
| > should we apply that solution to abort? Beats me.
|
| The simple answer is that there is such a thing as
| asyncronous reset and asynchronous abort is a handy way to
| disable properties in case such a reset occurs. I cannot
| envisage a similar natural use for asynchronous conjuncts and
| the like. If there is we could certainly provide that too.
I don't understand what you mean by "asynchronous conjuncts". I was refering to the fact that a property - any property - can be either clocked or unclocked. If clocked, the clock context uniformly affects the entire property, except where it's affect is blocked by a nested, explicit clock - OR if it is the RHS operand of the abort property. The latter fact appears to me to be an unnecessary special case.
| Why not take a liberal position here? As long as there is a
| use for it, and there are properties written with this
| semantics in mind and it is compatible with SVA, why not keep
| it? It doesn't preclude us from having syncronous abort as
| well. There is no problem from a user perspective here.
All of the PSL properties written prior to release of the PSL v1.1 LRM (and probably many that were written afterward) were most likely written with the abort semantics of PSL v1.01 in mind, in which the abort condition was sensitive to the clock. It would be nice if we could maintain backward compatibility with the original version of PSL, but I guess that's not an issue for anyone else.
| Certain vendors may perhaps face problems if they cannot
| easily support asyncronous abort but that is a completely
| different story.
My concern is not about what certain vendors can or cannot do. As always, I am arguing for consistency and simplicity in the language, and against unnecessary complication and complexity resulting from inconsistency. But as I said, I will stop arguing about this.
If we are going to keep the PSL v1.1 fixed-asynchronous semantics for abort, then I would at least recommend that someone (other than me) propose some changes to the informal semantics of abort, and perhaps also to the examples in the LRM that use abort, to make it clear to readers that the abort condition is asynchronous. There is no indication of this in the current LRM.
| > Cindy, I appreciate your point about the postfix operator being
| > visually hard to parse. I would only point out that the lack of an
| > explicit indicator that a directive is clocked is semantically hard to
| > 'parse'. Yes, you are right that we accomplish the same thing through
| > defining an explicit clock, but then we are no longer talking about
| > the ease of use that the default clock declaration was intended to
| > provide.
| >
| > In any case, I retract my proposal, and I will agree not to bring the
| > issue up again.
|
| What proposal?
My apologies - I confused two issues in the previous email. The next-to-last paragraph was regarding the proposal for changes to default clock. The last statement above was intended to refer to the proposal to restore the clock-sensitivity of the abort condition. It is the latter proposal that I withdraw.
Regards,
Erich
Received on Mon Jan 10 09:23:47 2005
This archive was generated by hypermail 2.1.8 : Mon Jan 10 2005 - 09:23:48 PST