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

From: <darren.galpin@infineon.com>
Date: Fri Sep 10 2010 - 00:27:45 PDT

PS. Making data_size undefined with no else error() is consistent then with the example in the next section 10.4.1.1.

________________________________
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:682552607@10092010-252A]

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.

Received on Fri Sep 10 00:28:14 2010

This archive was generated by hypermail 2.1.8 : Fri Sep 10 2010 - 00:28:15 PDT