Subject: RE: comments on array proposal
From: Simon Davidmann (simond@co-design.com)
Date: Thu Apr 11 2002 - 10:40:52 PDT
>
> You can write to any location in a scalar, and read from any
> location. Writing to the defined location is the only one that
> will have any effect; and reading from the defined location is
> the only way you have any hope of reading anything but 'x'.
sounds like some deprecation is needed here... because this seems silly and
should be avoided.
if I read or write off the end of vector I would like to know it.
same for scalars
surely!
> The historical reason for this is that schematic capture tools do
also we need to move away from schematic entry tools?
Simon
At 08:36 AM 4/11/2002, Michael McNamara wrote:
>Paul Graham writes:
> > > Question of the value to be returned when an error input is provided
> to a
> > > function like $left. Should return X. Generally decided after
> discussion.
> >
> > I think we should report an error for attempting to select a nonexistent
> > dimension. It's somewhat analogous to indexing a scalar. You aren't just
> > getting the bounds wrong, you are completely mistaking the type of object
> > you're dealing with.
>
> Your example is quite pertinent.
>
> In Verilog it is perfectly legal to index a scalar. Scalars that
> have no dimension defined are actually treated as if they were
> vectors, declared as:
>
> reg [0:0] a;
>
> In truth, scalars can be best thought of as a handy short cut for
> defining vectors that are one bit wide, indexed at zero.
>
> Note you could chose to define a single bit vector (aka scalar)
> with arbitrary dimensions, each the same, which are not zero:
>
> reg [1364:1364] b;
>
> You can write to any location in a scalar, and read from any
> location. Writing to the defined location is the only one that
> will have any effect; and reading from the defined location is
> the only way you have any hope of reading anything but 'x'.
sounds like some deprecation is needed here... because this seems silly and
should be avoided.
> The historical reason for this is that schematic capture tools do
> (did) not have a seprate notion of scalars and vectors; but
> instead unify them into a single the concept of 'nets' that have
> a base dimension and a width; and hence will (used to) generate
> for a single bit AND gate:
>
> and (o[0], i1[0], i2[0]);
>
> and this will work whether 'o', 'i1', and 'i2' are defined as
> scalars, or as degenerate vectors.
>
> > > $increment sounds better than low, high
> >
> > I don't see how you can write a loop with $left and $right and $increment
> > without also getting the min and max of $left and $right (which is
> what $low
> > and $high are):
> >
> > for (i = `MIN($left(A, 1), $right(A, 1));
> > i <= `MAX($left(A,1), $right(A(1));
> > i += $increment(A, 1)) ...
>
> One could do:
>
> for ( i = $left(A,1);
> i != $right(A,1)+$increment(A,1);
> i = i + $increment(A,1)) ...
>
>where $increment is defined to be
> '1' if $left(A,1) is less than $right(A,1); and
> '-1' if $left(A,1) is greater than $right(A,1); and
>
> >
> > Or to go from $left to $right using $incrment, you have to conditionally
> > compare:
> >
> > for (i = $left(A, 1); $left(A, 1) > $right(A, 1) ? i >= $right(A,
> 1) : i <= $right(A, 1); i += $increment(A, 1))
> >
> > Doesn't this look nicer?
> >
> > for (i = $low(A, 1); i <= $high(A, 1); i++)
>
> Yes, it does look nicer.
> >
> > In this example, since we are going from $low to $high, $increment is not
> > necessary (it's +1 by definition). So I vote we keep $low and $high. I'm
> > still not sure how you would use $increment.
> >
> > Paul
This archive was generated by hypermail 2b28 : Thu Apr 11 2002 - 10:44:23 PDT