Subject: summarry of $root proposals
From: Stefen Boyd (stefen@boyd.com)
Date: Mon Nov 26 2001 - 17:31:01 PST
Below are a list of the various proposals that have been
made to restrict the undesirable affects of $root. I have
included Peter's proposal from the face-to-face(4) and
since it's taken me a while to finish this, I've included
Kevin's extern proposal(5). I've added additional details
to Kevin's proposal that hopefully don't depart from his
original intent.
Proposal 1: Restrict $root constructs to typedef and constants.
Proposal 2: Restrict access to some $root constructs.
Proposal 3: Restrict $root location (single location)
Proposal 4: Restrict $root location (two locations)
Proposal 5: Explicit access to $root constructs
========================================================
Proposal 1: Restrict $root constructs to typedef and constants.
Since the primary reason most of us want to have $root
is to allow for global types that are shared across all
files (so we won't need to use `define), this proposal
limits spaghetti code by eliminating the most abusable
constructs.
Examples of permitted contructs:
const char colon = ":" ;
parameter myval=23;
typedef int foo;
typedef enum {NO, YES} boolean;
typedef struct {
bit[7:0] opcode;
bit [23:0] addr;
} instruction; // named structure type
typedef union { int i; shortreal f; } num; // named union type
Examples of forbidden constructs:
instruction IR; // define variable
num n;
task xxx; ... endfunction
begin
#20;
xxx;
end
Pro: Can't do obscure "defparam-like" spaghetti-code.
Con: Severely restricts the constructs allowed in $root
========================================================
Proposal 2: Restrict access to some $root constructs.
Only allow prefix-less access to types and constants in
$root. Everything else would require an explicit "$root."
prefix.
This is a variant of Proposal 1 that allows everything
in $root, but limits what can be accessed without
a "$root." prefix.
Using the following in $root:
const char colon = ":" ;
parameter myval=23;
typedef int foo;
typedef enum {NO, YES} boolean;
typedef struct {
bit[7:0] opcode;
bit [23:0] addr;
} instruction; // named structure type
typedef union { int i; shortreal f; } num; // named union type
instruction IR; // define variable
num n;
task xxx; ... endfunction
This module is valid:
module abc;
num n;
char s=colon;
initial $root.xxx;
endmodule
This module is invalid:
module def;
initial begin
n.i = 14;
xxx;
end
endmodule
Pro: Can't do obscure "defparam-like" spaghetti-code and
full syntax still usable in $root.
Con: "$root." prefix must be used in order to access anything
other than types and constants.
========================================================
Proposal 3: Restrict $root location (single location)
Given code such as the following:
// $root section "A"
module one;
endmodule
// $root section "B"
module two;
endmodule
// $root section "C"
module three;
endmodule
// $root section "D"
This proposal limits all $root related code to fall into
one of the sections identified by A through D. This has
no restriction on the contents of $root, but the $root
space "ends" when a module/primitive/macromodule declaration
is encountered.
For example, if $root code is placed in the region between
the end of module one and the beginning of module two (section
"B"), it would be an error to try to add additional
declarations, wires, variables, etc. to sections "C" or "D".
Pro: $root constructs used inside modules as globals are
contained in limited portion of source deck.
Con: same as pro.
========================================================
Proposal 4: Restrict $root location (two locations)
This uses the same example code as provided in Example
3.
Instead of restricting $root to any one region between
module/primitive/macromodule declarations, $root
constructs are allowed before the first module and after
the last module, but not between. In the preceding
example, this would allow $root constructs in sections
"A" and "D". Any attempt to put $root constucts into
"B" or "C" would be an error.
This has the same Pro and Con as Proposal 4.
========================================================
Proposal 5: Explicit access to $root constructs
This is a variant of Proposal 2 that allows access to
tasks, functions, and modules by using an extern
declaration. I've included Mac's amendment and have
included all the non constant and type stuff as
"extern"-able. The extern is also required to be
inside the module boundary. We don't solve any problems
if we let the module use $root forward declarations.
I didn't show any examples for extern module...
Using the following in $root:
const char colon = ":" ;
parameter myval=23;
typedef int foo;
typedef enum {NO, YES} boolean;
typedef struct {
bit[7:0] opcode;
bit [23:0] addr;
} instruction; // named structure type
typedef union { int i; shortreal f; } num; // named union type
instruction IR; // define variable
num n;
task xxx; ... endtask
task yyy; ... endtask
This module is valid:
module abc;
num n;
char s=colon;
extern task yyy; endtask
extern instruction IR;
initial begin
$root.xxx;
yyy;
IR.addr = 24'h0;
end
endmodule
This module is invalid:
module def;
initial begin
n.i = 14;
xxx;
yyy;
IR.addr = 24'h0;
end
endmodule
Pro: Can't do obscure "defparam-like" spaghetti-code and
full syntax still usable in $root.
Con: "$root." prefix must be used in order to access anything
other than types, constants, or externs.
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Mon Nov 26 2001 - 17:53:10 PST