Subject: Re: More issues
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Mon Dec 30 2002 - 09:02:07 PST
At 05:31 PM 12/26/02 -0800, Dave Rich wrote:
>> > >
>> > >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.
I do not have a copy of the ANSI C standard definition in front of me, so I
cannot give you the exact wording,
but the idea is that a statement can assign only once to a single
variable. Brad, can you look up the wording
again?
The proposal I sent out for auto-increment allows tools the option of
issuing an error in the event of multiple assignments, but does not require
tools to do so. For synthesis, I believe this is a good restriction
because it ensures that two different interpretations of a statement
(Formal and Synthesis) will get the same values.
>Dave
This archive was generated by hypermail 2b28 : Mon Dec 30 2002 - 09:02:52 PST