Subject: RE: [sv-ac] parsing problem
From: Bassam Tabbara (bassam@novas.com)
Date: Mon Dec 15 2003 - 11:44:42 PST
I never liked the bare "##" anyway.... However it does serve a
*practical function* which is: a specific number is rather confusing. If
I were to go with a specific delay number there I would rather it was 0
... Essentially the thinking is that any delay refers to the *current*
clock so "0" is more adequate. ##1 bugs me since we really mean go to
"earliest" different clock (from right now, not a cycle later...).
See what I mean by: it serves a practical function ? :-)! That said,
what is the problem we are trying to solve again ? I would rather we not
make the "optional" bit in the clock flow (if someone uses the
multi-clock concatenation they better switch the clock, if they don't
well they can put it again ... :-)!).
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of John Havlicek > Sent: Monday, December 15, 2003 7:15 AM > To: sv-ac@eda.org > Subject: [sv-ac] parsing problem > > > All: > > Surrendra has pointed out that my proposal 12 on clock flow > introduces a parsing problem. I am not well enough versed in > lexical analysis and parsing to give you a technical > characterization of the problem, but I will describe it. > > The proposal makes optional the specification of the clock in > places that it is redundant. Thus, it is not necessary to > write a clock event after the multi-clock concatentation "##" > if the clock does not change. This makes it somewhat tricky > to figure out whether what follows "##" is a parameter > expression for a "##n" operator or a sequence expression that > is the right-hand operand of "##". For example > > @(c) s ## 2 ## 3 ## 4 ## 5 ## 6 > > vs. > > @(c) s ## 2 ## 3 ## 4 ## 5 ## 6 7 > > The latter actually means > > @(c) s ##2 ##3 ##4 ##5 ##6 7 > > A simple solution is to change the multi-clock concatenation > symbol so that it is not identical to the base operator > symbol for the parameterized concatenations "##n". > > Surrendra and I have discussed an alternative solution that > may be better. The alternative is to get rid of the special > symbol for multi-clock concatenation and just use the > parameterized "##n" in both > singly- and multiply-clocked sequences. In the formal > semantics, "##" means the same thing as "##1", so to get the > effect of the old "##" one would write "##1" instead. > > For example, > > OLD: @(c) s ## @(d) t > > NEW @(c) s ##1 @(d) t > > One could also use any "##n", n > 0, when changing the clock: > > OLD: @(c) ##(n-1) 1 ## @(d) t > > NEW: @(c) ##n @(d) t > > The intuition for "##n", n > 0, in any sequence, whether singly- or > multiply-clocked, is then the following: > > s ##n t > > means that from the ending point of s, there are n clock tick > advances to get to the starting point of t. The first n-1 of > these advances are to clock ticks of the ending clock of s, > while the last advance is to a clock tick of the leading clock of t. > > Best regards, > > John H. >
This archive was generated by hypermail 2b28 : Mon Dec 15 2003 - 11:45:17 PST