Subject: Re: More issues
From: Dave Rich (David.Rich@synopsys.com)
Date: Thu Dec 26 2002 - 17:31:16 PST
> > >
> > >1. Treating assignments as expressions is a bad idea. Just because something
> > > is done in C doesn't mean it has to be copied. Expression side-effects
> > > are undesirable in Verilog because they mess up the combinational behavior
> > > of continuous assignments. We should not be deliberately adding more
> > > side-effects to cause problems.
> > >
> > This feature is frequently used in while loops to test the return value
> > of a function.
>
> [presumably in some other language; not Verilog].
>
> Further, allowing
>
> while ( more_work(a) ) begin
>
> end
>
> would make it no longer possible to detect the call of a function
> from the call of a task syntactically. The benefits are not yet
> compelling.
>
I don't understand your point. "more_work" must be a function because a
return value is required for the while loop expression. The example I am
thinking about is:
while((c = $fgetc ( fd )) != EOF)
begin
...
end
>
> > Combinational behavior is a matter of synthesis style. Those tools are
> > free to accept or reject assignments as expressions.
>
> And then System Verilog isn't a standard, but a guideline. Ladies
> and Gentlemen, it is not a feature that only a subset of Verilog is
> synthesizable. To introduce a construct that would very naturally be
> used in the design part of Verilog, and not demand that it be
> sythesized is not helping the world, IMHO. So we end up with two
> less than compelling arguments in favor of this new feature; and then
> also an indications that the supported would be willing to make this
> non sythesizable? Seems pretty weak. My recollection had the
> original CoDesign donation being the Sythesizable Subset of
> SuperLog. Was this intended to be sythesizable or not?
>
SystemVerilog is not just for synthesis. That is why the SV-EC committee
exists.
>
> > >2. The increment and decrement operators also introduce side-effects, as
> > > defined in the 3.0 document. This is bad. Treating them as assignment
> > > statements instead of expressions would solve this. It would still allow
> > > their use in for-loop increments, which is the main place they would be
> > > useful. Most of the "clever" uses of increment operators in C code are
> > > poor programming style. Only allowing these as statements would also
> > > resolve all the issues of evaluation order that have arisen over these
> > > as operators.
> > >
> > >
> > What about as a bit select index?:
> > word = mem[i++];
>
>
>
> This way the loop bookkeeping is all in one place, so the body of the
> loop can be written and managed without requiring careful ordering of
> the source.
>
> > Someone had suggested earlier that we allow only one assignment to the
> > same variable per statement unit.
>
> What is a statement unit?
>
> How would this help?
>
> Wouldn't this outlaw 'word = mem[i++];'
>
This would outlaw 'word = mem[i++] + mem[i++];', '--i++', and 'i = i++;'
I'm hoping the person who said this will speak up. I don't remember who
or exactly what they said. A statement unit is something like a
statement not including the statements that might be part of function
calls within the statement.
Dave
This archive was generated by hypermail 2b28 : Thu Dec 26 2002 - 17:31:47 PST