From: Steven Sharp (sharp@cadence.com)
Date: Mon Nov 06 2000 - 11:02:12 PST
This case already exists in the language. Delays do not have to be constant
expressions, so constant functions are not required for this to occur. That
means that I can test it with both XL and NC.
Both assume that delay_val is a parameter rather than a function, and that
the parenthesized list after it is the port list for a nameless instance.
If the comma is not present, they produce a syntax error at that point. In
the unlikely event that someone actually wants a function there, parentheses
around the delay expression give the desired effect.
This is presumably Phil Moorby's fault, and we are stuck with it now. At
least it isn't likely to come up much.
I should have spotted the problem with the ANSI ports, but I just considered
it long enough to determine that it was not ambiguous. As James points out,
the grammar can be expressed in a way that is LALR(1), but it is awkward
(and slightly more so when you have to embed semantic actions). I think we
should modify the language to avoid it.
> From owner-btf@boyd.com Mon Nov 6 09:25 EST 2000
> X-Authentication-Warning: phobos.magic.com: smap set sender to
<jam@mist.magic.com> using -f
> Date: Sun, 5 Nov 2000 15:41:07 -0800 (PST)
> From: "James A. Markevitch" <jam@magic.com>
> To: mac@verisity.com
> Subject: Re: shift-reduce conflict in verilog-2000 grammar
> Cc: btf@boyd.com
> X-Received: By mailgate2.Cadence.COM as GAA04609 at Mon Nov 6 06:25:38 2000
>
> > > However, the new grammar saddly introduces a reduce/reduce conflict,
> > > which makes the grammr non LALR(1) in practice, and hence impossible
> > > to parse with yacc. [James might share with us his magic solution...]
> ...
> > I don't recall the exact construct which requires the infinite lookahead,
> > and need to run to a meeting, so I can't look it up. But, the "magic
> > solution" to this is seriously seriously ugly; if I recall, it involves
> > communication between the lexer and parser and an infinitely deep stack,
> > but I am not positive.
>
> I had a chance to think about this over the weekend, and now remember the
> particular case.
>
> Consider the following fragment of code:
>
> and #delay_val (a, b, c, d)
> (e, f, g);
>
> Looks like a parameterized delay and two AND gates. No, there's no comma
> at the end of the first line. What's up? delay_val is a constant function
> and "a, b, c, d" are arguments being passed to it. This is just one unnamed
> AND gate with an output "e" and inputs "f" and "g" and a delay specified by
> a constant function call "delay_val(a,b,c,d)".
>
> The grammar is unambiguous, but you need to scan all the way to the second
> open paren to decide whether delay_val is to be treated as a parameter or
> as a constant function call.
>
> If we had seen (with the comma):
>
> and #delay_val (a, b, c, d),
> (e, f, g);
>
> Then we would have two AND gates, and delay_val would be a parameter
> specifying the delay.
>
> Since we cannot rely on constant functions being declared before they are
> used, we cannot cheat by looking in the symbol table to determine if delay_val
> is a constant function or not.
>
> James Markevitch
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:15 PDT
and
sponsored by Boyd Technology, Inc.