RE: Problem with the named constraints example on page 178 of the latest draft

Hi,

Sorry for the delayed reply - a network failure somewhere in London meant that there was no connection to the web for me yesterday.

I think that the solution here is quite simple, and that the example should read "keep data_size is undefined", losing the else error() construct, which is consistent then with how undefined is used elsewhere in the LRM, and would allow the example to be syntactically correct, although the over-ride later needn't use "is only", and would only require "is".

Is this OK for the example - Matan, what do you think?

Cheers,

Darren

________________________________
From: Brett Lammers [mailto:brettl@cadence.com]
Sent: Wednesday, September 08, 2010 5:26 PM
To: Galpin Darren (IFGB ATV MCD CV)
Cc: Yaron Kashai
Subject: Problem with the named constraints example on page 178 of the latest draft

Hello Darren,
                I apologize for the last minute issue but I have been crazy busy and have had to put off my review of the draft until today.

Anyway in my review I was spot checking a few examples listed in the Draft in Specman and ran into some issues with the example mentioned (page 178 "Syntax example (named constraint):")

One issue was just a simple typo (unit=>uint) which I submitted mantis issue 3199
 The other issue I was not as sure whether it was a Specman issue or a Spec issue so I conferred with Yaron and some others in Cadence and Yaron's response was the following:
------------------------------------------------------ From Yaron -----------------------------------------------

Thanks Brett!

This seems broken to me. The example does not adhere to the LRM spec - meaning the LRM is inconsistent, regardless of Specman. In particular:

> keep data_size is undefined else error(...)

should match the syntax:

keep NAME is BOOL-EXP else error(...)

and "undefined" is not a BOOL-EXP.

I think there is no choice but to "stop the press". Let's start by notifying Darren. Someone on the R&D side should investigate the origin of this example and the intention behind it...

As such I will submit another issue...should I do anything else?

[cid:305481707@10092010-251C]

Brett Lammers | Senior Technical Leader, Solutions Deployment Group

P: 303.579.6721 www.cadence.com<http://www.cadence.com>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.