Subject: Re: comments on array proposal
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Thu Apr 11 2002 - 10:05:23 PDT
> From pgraham@cadence.com Thu Apr 11 09:35:08 2002
> From: "Paul Graham" <pgraham@cadence.com>
> To: dkc@galaxy.nsc.com
> cc: vlog-pp@eda.org
> Subject: Re: comments on array proposal
> Reply-to: pgraham@cadence.com
> X-Received: By mailgate2.Cadence.COM as JAA23450 at Thu Apr 11 09:36:57
> 2002
>
> > I thought you didn't like redundancy in an LRM :-)
>
> I don't like describing the same rule twice. Providing two ways to
> do things isn't necessarily a bad idea.
>
> > I'd rather have '$range', it would be more forward
> > compatible if we decide to allow increments other
> > than 1. Keep $left,$right & $increment for now and
> > add ranges in 3.1?
>
> How would $range be used? What is the syntax? Would it be a macro
> to be used like:
>
> $range(i, A, 1) {
> }
>
> or
>
> for (i = $range(A, 1)) {
> }
Maybe a different operator, but I think that would reasonable syntax.
>
> or what?
>
I was thinking you could declare ranges like typedefs:
range [31:0]B32;
reg [B32] data[1:0];
for (b @= $range(data,1)) if (data[b][0]) ....
You could ask for $left,$right and $increment of a range, so
it could be passed to routine
function af(input range rng1)
if ($left(rng1) == $right(rng1)) ...
endfunction
...
af($range(data));
Might want to add a boolean "$packed(<range>)" function for completeness.
I think most simulators have common internal structures for holding ranges,
so it probably wouldn't cost a lot to implement, and it avoids having to
decompose the range data unnecessarily at run-time.
However, I'd suggest leaving the discussion of $low,$high and [$]range for 3.1.
Kev.
This archive was generated by hypermail 2b28 : Thu Apr 11 2002 - 10:07:28 PDT