From: Clifford E. Cummings (cliffc@europa.com)
Date: Thu Jun 05 1997 - 09:57:03 PDT
Subject: BTF - B25 - Add struct / record data types
Behavioral Task Force - Enhancement Request
Assigned Enhancement Request Number: B25
Enhancement Name (Description): Add struct / record data types
Date Submitted: 970514
Requestor: vivek@veri-log.com (Vivek Sagdeo)
Status: Submitted (priority not yet assigned)
Is enhancement intended to be synthesizable?:
Rationale : structs or records are widely used in higher level
languages to group items together that belong together.
This addition to Verilog HDL will give it one more feature
to bring it to higher level behavioral/programming language.
Constructs to add:
1. 'structure' declaration :
structure cpu_regs
reg [7:0] a;
reg [7:0] b;
reg [7:0] c;
endstructure
2. Accessing capability within a structure using the '.'
s.a, s.b, s.c
This adds a scope and same symbol as scope is used here.
3. Passing as parameter : Either the whole structure or parts can be
passed as a parameter.
From: Adam Krolnik <adamk@cyrix.com>
Date: Wed, 14 May 97 12:52:47 +0600
Structures must then be nestable!
Can you place arrays in a structure?
tructure cache_line
reg[31:0] word[7:0];
endstructure
Can you initialize structure members, if you allow
"reg a = 2;" (BTF-BT14)? Can you initialize structures?
tructure a
...
endstructure = 0; // extended to size of structure (BTF-BT11)
Can you perform a bit-selection of a structure? Which way are the bits
defined; 3:0, 0:3?
May we have an optional size specification which is checked against
the number of bits specified in the structure? It is tedious to figure out
that you have one extra/fewer bit, shifting a field over.
tructure [31:0] cmd
reg[6:0] command;
reg[3:0] master;
reg[3:0] size;
reg[15:0] data;
endstructure
// Warning, size of structure greater than size of fields.
[// Error, size of structure less than size of fields!]
Should greater be a warning, while lesser be an error?
From: <mac@silicon-sorcery.com>
Date: Wed, 14 May 1997 10:02:34 -0700 (PDT)
1) I would like to ammend your proposal, changing the word "parameter" to
"port" in every occurance.
2) As a port, one is reasonably required to support structured wire
declarations (at least to accept the value through a port as other than a
degnerate wire (see (4) below)). Hence I also would like to ammend the
proposal to allow use of net declarations in structures, and further to
mandate that a structure must consist entirely of a homogeneous collection
of elements. (That is to say if any elements are reg, they must all be reg,
and that if any are wand, they must all be wand, and so on. I would allow
the mixing of signed and unsigned types.)
3) Considering the above, I would find it very useful to have a typedef
declaration for structures, so that I could layout the bits once, and then
define objects that are of the particular structure. This leads to problems
where some times I am defining a register of the structure type, and at
other times I am declaring wires; hence reasonable syntax needs to be developed.
4) The degenerate case, of passing a struture to a module expecting a simple
wire, (or accepting a connection from a simple wire at a port declared to be
a structure) requires a layout definition of the individual pieces of the
structure in a simple container. I would propose that there be no
alignment, and that such an assignement be treated as if one passed
{s.a,s.b.s.c} to the port.
5) One would also like to assign the entire structure to a wire, or load a
register with the value of the entire structure; again I would propose that
the statement
structure cpu_regs
reg [7:0] a;
reg [7:0] b;
reg [7:0] c;
endstructure
reg [23:0] r;
initial
r = cpu_regs;
be treated as if it were:
r = {cpu_regs.a,cpu_regs.b,cpu_regs.c};
6) PLI clearly needs to voice an opinion here.
7) This is a BIG change.
From: tan@silicon-sorcery.com
Date: Wed, 14 May 1997 10:27:45 -0700 (PDT)
I like to add a few points :
8) The "." is current part of the Verilog syntax (not convention), which
is reserved for hierarchical reference. Using "." for accessing
member of structure can have significant implication in PLI.
9) For a structure to be useful, it need to be hetreohomogenous. That
is, we need to be able to group together all Verilog wire/reg types
in a structure. Since wire connection to instances are "called by
references", where reg are "called by value" when it is allowed. The
proper behavior on connecting a structure to an instance port must
be establish. This can be a designers nightmare.
10) We need to pay attention to the new syntax. The commonly used
YACC is a LALR parser, we don't want to make the Verilog language
LR(2). Having a LR(2) language is like having another VHDL.
11) The new syntax and functionality of structure is going to
introduce inconsistency among simulators. This will defeat the
purpose of having a standard if not carefully conceived.
<p>From: Vivek Sagdeo <vivek@professionals.com>
Date: Thu, 15 May 1997 08:35:48 -0700 (PDT)
All the points raised by Mike Mcnamara(mac@silicon-sorcery.com), Tan
(tan@silicon-sorcery.com) and Adam Kronolik (adamk@cyrix.com) relate to the
details of the proposed enhancement.
Here is a refined spec. that will address the 12 points in Mac and Tan's
messages and the issue of nesting and wire/reg from Adam.
1. 'structure' declaration :
structure cpu_regs
reg [7:0] a;
reg [7:0] b;
reg [7:0] c;
endstructure
The declarations inside can be any type of valid Verilog declarations
including vectors, memories (and multi-dimensional arrays as in Verilog-97).
However, while using these at ports in module declarations or ports in
module instances or as parameters to tasks and functions, rules must be
followed of their use. These are explained in items 3 and 4 below.
2. Nesting of records:
Structures can include other structures within them just like "C". The
other structures must be declared separately.
3. Typedefs - This is a separate item and will be a new BTF item.
This is defined in the next mail message. As seen there, typedefs are
allowed on structures and other types. This allows one to define names for
types. However, structures define types without typedefs in their own
right. These can be reused using 'strucure sname s1, s2, s3;' like syntax
just like in "C". Thus, typedefs are really not required for the anticipated
use of structures but can add more readability ot Verilog code.
4. Accessing capability within a structure using the '.'
s.a, s.b, s.c
This adds a scope and same symbol as scope is used here.
Using the same symbol as hierarchical references is consistent and
unambiguous.
5. Passing as parameter : Either the whole structure or parts can
be passed as a parameter to tasks and functions. Here, one
can look at the structure as a concatenation of the items
declared within the structure.
6. Using records on ports :
Structures can be used be used on ports. Again, their use can
be viewed as a concatenation of items declared within. Thus,
only structures whose equivalent valid concatenations are allowed
in Verilog HDL are usable on ports.
7. structures can be used on left or right side of assignments and their
use is equivalent to concatenation of its items.
8. Ramifications on implementation :
This BTF item and the next one on typedefs mainly affects the
compiler and not so much the simulator.
9. Syntax :
New Keywords : structure endstructure
From 1364 syntax, add module_structure_declaration to module_item_declaration
and also to block_structure_declaration to block_item_declaration.
module_structure_declaration ::= structure
module_item_declaration
{module_item__declaration}
endstructure
block_structure_declaration ::= structure
block_item_declaration
{block_item__declaration}
endstructure
In addition, all places where concatenations are used, add strucure
identifiers.
Add strucure item references to the hierarchical naming.
Any other related changes while redefining complete bnf for 1364-97.
From: eli@interhdl.com (Eli Sternheim)
Date: Thu, 15 May 97 10:29:38 PDT
...
>
> 5. Passing as parameter : Either the whole structure or parts can
> be passed as a parameter to tasks and functions. Here, one
> can look at the structure as a concatenation of the items
> declared within the structure.
...
I wonder if it is advisable to permit a dual interpretation of a
structure as both a structure and as a concatenation. One possibility
is to interpret structure as a concatenation only inside a
concatenation. So, for example to interpret s as a concatenation, use
{s}.
From: Vivek Sagdeo <vivek@veri-log.com>
Date: Fri, 16 May 1997 08:55:13 -0700
The interpretation of structures as concatentations is given to explain the
semantics behind the structure construct. One can use the structures within
concatenations using { s1, s2, ... } construct.{s} is same as s for all
practical purposes. I am not expecting actual use of the concatenation
symbol while using strucures except when actually concatentating structures.
However, to understand the implications of use of structures at some places
in Verilog model, concept of concatentaion is used in the spec.
For example, on ports, a structure can be viewed as a concatenation of its
elements to decide on the semantics of hooking up a structure.
From: Mark Hummel <mdh@argo.net>
Date: Thu, 15 May 1997 17:04:06 -0400
>1. 'structure' declaration :
> structure cpu_regs
> reg [7:0] a;
> reg [7:0] b;
> reg [7:0] c;
> endstructure
>
>The declarations inside can be any type of valid
>Verilog declarations including vectors, memories (and multi-dimensional
>arrays as in Verilog-97). However, while using these at ports in
>module declarations or ports in module instances or
>as parameters to tasks and functions, rules must be followed
>of their use. These are explained in items 3 and 4 below.
Will an array of structures be allowed?
ex: structure cpu_regs regfiles[7:0];
rega = regfiles[i].a;
The combination of structures and arrays would be very useful for
complex repetitive logic.
I would also assume that members of a structure can appear in a
sensitivity list:
ex: always @( regfiles[0].a ) ....
This should only execute if the member 'a' changes. Note: 'a' could be another
structure type.
From: vivek@veri-log.com
Date: Fri, 16 May 1997 10:55:14 -0700 (PDT)
>Will an array of structures be allowed?
>ex: structure cpu_regs regfiles[7:0];
> rega = regfiles[i].a;
>
>The combination of structures and arrays would be very useful for
>complex repetitive logic.
This is in addition to original spec. In general, Verilg only allows arrays of
nets and regs and 2-dimensional arrays of regs that are memories.
There is a BTF of adding multidimensional arrays.
I do not see any problems in adding arrays of structures as an additional
construct in the definition of structures as given in your example above.
>I would also assume that members of a structure can appear in a
>sensitivity list:
>ex: always @( regfiles[0].a ) ....
>
>This should only execute if the member 'a' changes. Note: 'a' could be another
>structure type.
Yes, this is a correct usage. Members of structures can be used as event
sensitizers.
Again, interpretation of structures as concatenation of its elements is a valid
interpretation in this context as well.
//********************************************************************//
// Cliff Cummings E-mail: cliffc@europa.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:40 PDT
and
sponsored by Boyd Technology, Inc.