Re: [sv-ac] proposal for erratum 230

Hi Bassam:

I am still working on fixing the proposal. I uploaded the 230.pdf
this morning before we noticed this problem.

Given where I am, I think we need to leave the graphical notation
for later.

Thanks,

John H.

> Reply-To: <bassam@novas.com>
> From: "Bassam Tabbara"<bassam@novas.com>
> Date: Tue, 23 Nov 2004 10:02:13 -0800
> Organization: Novas Software, Inc.
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
> Thread-Index: AcTRghwQUx1XiAYKTDKSB3VlB3WBgwAAhwFw
> X-OriginalArrivalTime: 23 Nov 2004 18:02:23.0608 (UTC) FILETIME=[956E6780:01C4D186]
>
> Thanks for the catch John.=20
>
> 1) Indeed this would make a difference (because of the clause of =
> "inward to outward" clock determination).=20
>
> However, I downloaded "230.pdf" and I still see:
>
> "In a module, interface, or program with a default clocking event, =
> >>>>>all sequence
> Declarations<<<<, property declarations, and concurrent assertion =
> statements
> that have no otherwise speci=EF=AC=81ed leading clocking event are =
> treated
> as though the default clocking event had been written explicitly as the
> leading clocking event."
>
> How come ? Am I missing something ?
>
> 2) One comment I stopped short of sharing at the meeting because I did =
> not have an alternative at the time is: I lament the loss of some =
> graphical notation for the text. I like the text of the proposal a lot, =
> simple and to the point.=20
>
> I dislike the tables, they were not precise but now that I see the =
> something "supersedes" something else ... Can we may be have some sort =
> of (partial) order notation ? Seems only adequate (not a lattice :-) =
> just a one liner like: default clock < ... < (... | ...) < ... ), WDYT =
> ? Not too formal either just the idea ...
>
> Bottom line, I really think the visual notation is useful, but my =
> intent is not to overburden this proposal we can do that as a corollary =
> later if people think it's worth it ...
>
> Thx.
> -Bassam.
>
>
> --
> Dr. Bassam Tabbara
> Architect, R&D
> Novas Software, Inc.
> (408) 467-7893
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of =
> John Havlicek
> Sent: Tuesday, November 23, 2004 9:30 AM
> To: sv-ac@eda.org
> Subject: [sv-ac] proposal for erratum 230
>
> All:
>
> Doron and I have been proofreading and discussing the proposal for =
> erratum 230.
>
> After reading over the current text of 17.14, we found that the =
> proposal makes a change of substance that I did not notice before.
>
> My understanding of 17.14 in the current 3.1a LRM is that a default =
> clocking event applies only to concurrent assertion statements that are =
> not otherwise clocked. It does not apply to sequence or property =
> declarations.
>
> The proposal for erratum 230, as we discussed in yesterday's meeting, =
> says that a default clocking event applies to all sequence =
> declarations, property declarations, and concurrent assertion =
> statements that are not otherwise clocked.
>
> It seems to me that we do not need to apply the default clock to =
> sequence and property declarations, since the default clock will flow =
> starting from the concurrent assertion statements. Also, increasing =
> the scope of the default clock to include the declarations is not =
> backward compatible with 3.1a.
>
> Therefore, I am changing the wording of the proposal for erratum 230 so =
> that the default clocking event applies only to concurrent assertion =
> statements.
>
> Please send any comments or concerns as soon as possible.
>
> Best regards,
>
> John H.
>
Received on Tue Nov 23 12:45:34 2004