Re: gEDA-user: Yet another Icarus question

[Larry Doolittle <ldoolitt@xxxxxxxxxxxxxxx>]

On Wed, Aug 04, 2010 at 10:58:51AM -0400, Patrick Doyle wrote:
> Can anybody tell me if the following is an Icarus feature or a Verilog
> feature.

Verilog.  Probably.

> reg [5:0] offset;
> reg [9:0] enablemask;
>    initial begin
>      enablemask = 10'b00000_00110;
>      offset     = 0;
>      $display("%b", {enablemask, (16'h0 +  8'h80 + offset )});
>      $display("%b", {enablemask, (16'h0 + (8'h80 + offset))});
>    end

This can be explained as long as the default addition order
in Verilog is left-to-right, thus
"16'h0 +  8'h80 + offset"  is defined as "(16'h0 +  8'h80) + offset".

16'h0 +  8'h80  is 17 bits wide, to account for carry.
Adding the 6-bit offset to a 17-bit number also needs to
account for carry; the notion of a value-constrained
17-bit number is too subtle for Verilog.  Thus the
result is 18 bits.

With the other order of addition, 8'h80 + offset is 9 bits
wide, after accounting for carry.  Adding a 9 and a 16 bit
number, with carry, gives a 17 bit result.

Just this morning I got started again thinking about a post-Verilog
language that would have more powerful bookkeeping behind the scenes,
thus allowing more compact and reliable code.  Value-constrained
integers (or more generally, fixed-point numbers) are on the list.
The last time I wrote notes to myself about this was August 2009:

  Inspired by, but presumably not compatible with, the base Verilog language.
  It will need a translator so you get something that a synthesizer and
  simulator could handle.  In the long run, extending Icarus to handle this
  language would have advantages, especially in making a vcd (or lxt or ...)
  file that is more closely related to the original source.

   - Larry


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user