From: Adam Krolnik (adamk@cyrix.com)
Date: Mon Feb 23 1998 - 20:26:31 PST
Begin forwarded message:
From: Adam Krolnik <adamk>
Date: Fri, 20 Feb 98 15:54:04 +0600
To: adamk
Subject: BTF - B13 - Mutable bit selects
<p><p>Subject: BTF - B13 - Mutable part selects
Behavioral Task Force - Enhancement Request
Assigned Enhancement Request Number: B13
Enhancement Name (Description): Mutable part selects
Date Submitted: 970319
Requestor: adamk@cyrix.com (Adam Krolnik)
Status: RO
Is enhancement intended to be synthesizable?: yes
5. Mutable part selects
As part of developing verification code, one will store multiple fields
inside a register. It is tedious to write (and confusing to read without comments) code that alters specific fields in the register.
reg [63:0] qword_data, valid_byte;
integer ith;
//Set the ith byte in the qword to the new valid byte.
qword_data = (qword_data & ~(8'hff << 8*ith)) | valid_byte[7:0] << 8*ith);
or
case (ith)
0: qword_data[63:56] = valid_byte[7:0];
1: qword_data[55:48] = valid_byte[7:0];
2: qword_data[47:40] = valid_byte[7:0];
3: qword_data[39:32] = valid_byte[7:0];
4: qword_data[31:24] = valid_byte[7:0];
5: qword_data[23:16] = valid_byte[7:0];
6: qword_data[15:8] = valid_byte[7:0];
7: qword_data[7:0] = valid_byte[7:0];
endcase
Rather it would be easier to say.
qword_data[8*ith+7:8*ith] = valid_byte[7:0];
A HDL language should allow programmatic specification of bit selects,
rather than resorting to shifting and or'ing and and'ing. This construct is
simply removing a hinderance in specification (for software writing and
understanding.) Specification should be flexible and dynamic, rather than
mostly static.
[Ed: I would rather have fully mutable part selects (in position and size) but
this proposal only specifies variable positions since many are not in favor
of this anyways.]
----------------------------------------------------------------------------
Section 4.2.1 "Net and register bit-select and part-select addressing" 3rd
paragraph, first sentence now reads:
Both expressions shall be constant expressions. The first expression has to
address a more significant bit than the second expression.
The new wording proposed would be:
The expressions shall evaluate to a constant difference. The first expression has to
address a more significant bit than the second expression. The part select may
not select a variable number of bits, only a variable starting point.
<p>BNF
Section A.8 reg_lvalue and net_lvalue, and primary:
{reg,net}_lvalue ::=
{reg,net}_identifier
| {reg,net}_identifier [ part_selection]
| {reg,net}_concatentation
part_selection ::=
expression /* degenerate case -> bit_select */
| msb_constant_expression : lsb_constant_expression
| msb_constant_difference : lsb_constant_difference
constant_difference ::=
expression
| constant_expression + expression
| constant_expression - expression
| expression + constant_expression
| expression - constant_expression
primary ::=
number
| identifier
| identifier [ part_selection ]
| concatenation
| multiple_concatenation
| function_call
| ( mintypemax_expression )
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:46 PDT
and
sponsored by Boyd Technology, Inc.