Re: [Iverilog-devel] P1800-2009

[Williams T. <pha...@gm...>]

All,

I would be happy with just adding support for these "op-and-assigns" to be stand-alone statements (i.e., "a += 2;"  or "a--;"), if implementing their expression counterparts is too difficult at the moment.  If Icarus supported these as statements only for the time being, I would think that their implementation would be pretty straightforward even though not complete.  IV doesn't fully conform to the 2001 Verilog spec but that doesn't make what it does support in that standard to be useless.  As an example, I believe that there were released versions of IV that only partially supported the generate syntax.  Having some of the generate functionality was better than having none of the generate functionality.

Thanks,
Trevor



On Nov 27, 2009, at 3:12 PM, Jared Casper wrote:

> On Fri, Nov 27, 2009 at 1:41 AM, Evan Lavelle <sa2...@cy...> wrote:
>>  From what Jared says later it looks like assignment is an operator in
>> 1800 ("1800 allows assignments in expressions"). With this, and
>> post-increment and post-decrement, you basically get the whole
>> can'o'worms of side-effect evaluation, which is new to Verilog. FWIW, I
>> added this stuff to Maia a couple of years ago, and it basically ended
>> up as a rewrite. It's a completely different way of looking at things.
>> You also have to consider exactly when to handle the side-effect
>> evaluation - sequence points, as in C, or left-to-right evaluation, as
>> in Java, C#, etc? Is this specified in 1800?
>> 
> 
>> From P1800/D8:
> 
> "The ordering of assignment operations relative to any other operation
> within an expression is undefined. An
> implementation can warn whenever a variable is both written and
> read-or-written within an integral expression
> or in other contexts where an implementation cannot guarantee order of
> evaluation. For example:
> i = 10;
> j = i++ + (i = i - 1);
> After execution, the value of j can be 18, 19, or 20 depending upon
> the relative ordering of the increment
> and the assignment statements."
> 
> This should make the implementation much easier.  But I think
> can'o'worms is a good description of allowing assignment operations.
> :)
> 
>> My 2p: SystemVerilog isn't Verilog. It's a vast set of extensions which
>> were railroaded in by one vendor to protect their position in the
>> market, 10 years after the problem had already been solved, cleanly, by
>> 'e'. The entire language is predicated on the belief that engineers
>> should use the same language for design and verification, despite the
>> fact that design and verification are completely different activities,
>> and are carried out by different engineers, with completely different
>> mindsets.
>> 
> 
> I mostly agree, if I ran the world 1800 and 1364 would not have
> merged. There's a pretty nice blog post/article by Phil Moorby
> ("inventor" of Verilog) along those lines:
> http://www.edn.com/blog/920000692/post/1580043358.html.  I've found it
> is especially frustrating trying to teach Verilog to students, who
> invariably end up trying to synthesize code that uses features meant
> for verification.
> 
> That said, I think there are some pretty nice enhancements in
> 1800-2009, I just wish they had come as small changes in a 1364-2009
> instead of coming in with hundreds of pages of other stuff (P1800/D8
> is 1258 pages!).  I certainly don't need classes in a hardware
> description language. But then who am I to say what should and
> shouldn't have come in?  If some, then why not all?  I'm sure this was
> all debated ad nausem in convincing people to approve the merge.
> 
> Jared
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel