From: Michael McNamara (mac@surefirev.com)
Date: Tue Feb 24 1998 - 12:45:34 PST
Thomas Fitzpatrick writes:
> Hi Adam,
>
> I've run this by one of our Verilog implementers here, and this is what
> he thinks. Any other thoughts?
>
> >
> > I would rather build this stuff into the grammar than require
> > additional downstream semantic checking. For example, there should be
> > (I believe this was implied but not directly stated) semantic
> > requirement that the part-select acutally has to look like
...
> > Imagine the complexity of the checking for this. Therefore, I propose
> > a syntax which only specifies the variable expression once, something
> > like (I am very open to other suggestions):
> >
> > [8*ith +: 7] means [8*ith : 8*ith+7]
> > or [8*ith -: 7] means [8*ith : 8*ith-7]
> > [7 +: 8*ith] means [8*ith+7 : 8*ith]
> > [7 -: 8*ith] means [8*ith-7 : 8*ith]
> >
> > It's pretty ugly, but this is only my quick and dirty idea, if someone
> > can think of a better syntax I'm all for it, as long as it meets my
> > desire for no semantic validation requirement.
> >
Ok, this is getting much better in my opinion.
Adam Krolnik writes:
>
>
> I am worried that this specification of a constant difference and
> the requirement of the simulator to verify this will eventually be
> the undoing of this proposal. I am opposed to another syntax for
> specifying this constant difference, and would rather see the
> proposal bite the bullet and specify a fully dynamic part select
> instead. Yes this is harder than a constant difference, but a
> richer ability.
So rich that it will clog the arteries...
I can not support allowing arbitray runtime expressions for the
arguments to a partselect. Imagine:
assign a = b [c:d];
where sometimes c is greater than d, some times less...
worse, consider the concatenation:
assign a = {3'b110,b[c:d],5'b01101};
Does the 3'b110 move up and down in the number as c and d move
about?
And note that even given the user coding up:
assign c = d + 7;
assign a = {3'b110,b[c:d],5'b01101};
initial begin
d = 0;
#10;
d = 20;
end
there is the bit of time after d has been updated from 0 to 20, that
one could evaluate either a of c first; and should one choose to
update a first, and it propogates to other places, you get this weird
assign a = {3'b110,b[7:20],5'b01101};
which is presently illegal and even if made legal, may trigger
all sorts of bad stuff.
>
> Maybe our discussions on BTF-B25 (struct/record data types) will
> make it easier to get the effect of mutable part selects.
>
Could be, but that is that proposal, and this is this proposal
. I could support Tom's direction (the operator '+:' brings to mind
specify blocks in a rather distasteful manner). I like the clear
specification of the width of the partselect as a constant_expression;
this greatly helps the designer, and the reader of the code:
assign a = {3'b110,b[c+:7],5'b01101};
make it clear to me the overall width is 3+7+5, and where the
constant bits end up. Folks might even switch whole hog:
assign a = {3'b110,b[167 +: 14 ],5'b01101};
may be deemed easier than doing the math.
--
/\ Michael McNamara <mac@surefirev.com>
/\// SureFire Verification Inc.
/\///\ <http://www.surefirev.com>
_\///\/ Formerly Silicon Sorcery
\//\/ Get my verilog emacs mode from
\/ <http://www.surefirev.com/verilog-mode.html>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:46 PDT
and
sponsored by Boyd Technology, Inc.