From: Clifford E. Cummings (cliffc@europa.com)
Date: Tue Aug 12 1997 - 11:55:59 PDT
BTF Conference Call Notes and Proposals - 08/08/97 - Thanks to Anders
Nordstrom and Nortel
Attendance: Tom Fitzpatrick, Cliff Cummings, Vivek Sagdeo, Anders
Nordstrom, Mike McNamara, Kurt Baty, Karen Pieper, Eli Sternheim
Key: pass/fail (for)-(against)-(abstain)
-----------------------
B01 Notes:
Kurt Baty to do the BNF -
Suggested BNF name: generate_constant
nested "generate" for-loops
Proposal: generate - endgenerate can only exist at the module scope - pass
5-2-1 (opposing - no new keywords should be introduced)
Proposal: genvar - for the generate for-loop: a generate-loop index
variable should be declared - pass 6-0-2
Proposal: new keyword genvar required - pass 6-1-1 (opposing - no new
keywords should be introduced)
Proposal: genvar is local to (may only be used within) the generate-scope -
pass 7-0-0
Proposal: genvar shall be declared within the module, either inside or
outside of the generate-loop, and its scope is the scope of the module.
Proposed by Kurt Baty - 2nd by Mike McNamara - pass 7-0-0
Proposal: case may test against an expression made up of constants and/or
genvars - Proposed by Mike McNamara - 2nd Kurt Baty - pass 7-0-0
Proposal: if-then-else may test against an expression made up of constants
and/or genvars - Proposed by Mike McNamara - 2nd Kurt Baty - pass 7-0-0
Proposal: Multiple square brackets are allowed in the instance hierarchical
reference, the bracketed values are constant expressions and can optionally
be followed with a period and another hierarchical reference. Proposed by
Kurt Baty - 2nd by Anders Nordstrom - pass 7-0-0
---------------
B02 Notes -
Mike McNamera to do the BNF -
(Use-Model #1 - additional ranges after the variable name) -
reg [range1a] variable1 [index2a] [index3a],
variable1 [index2a] [index3a];
wire [range1b] variable3 [index2b] [index3b],
variable4 [index2c] [index3c];
// Normal Verilog memory declaration follows
reg [range1d] memory_name [memory_range]; //memory
<p>Proposal: Multi-dimensional array declarations shall consist of:
net & reg types [range] element [index1][index2]à ;
Proposed by Cliff Cummings - 2nd by Kurt Baty - pass 7-0-1
Proposal: A full index1,index2 of elements shall not be accessed in a
single reference Proposed by Karen Pieper - 2nd Cliff Cummings- pass 7-0-1
Proposal: Referencing the elements of a multi-dimensional array is of the
form element[index1][index2]...; Proposal Kurt Baty - 2nd Tom Fitzpatrick -
pass 7-0-1
(in-work) Proposal: bit- or part-select indexing into a multi-dimensional
element -
---------------
B03 Notes -
Mike McNamara to submit file I/O proposal including $writemem commands,
UNIX/PLI file I/O commands and his fscanf variations -
Proposal B3(a) - Add $writememb & $writememh to the IEEE 1364 LRM.
Proposal B3(b) - Add UNIX-like file I/O capabilities to the IEEE 1364
LRM.
Proposal B3(c) - Add useful existing PLI file I/O routines.
---------------
B04 Notes - Re-entrant Tasks
Dear Behavioral Task Force members, please comment on the task ideas shown
below.
Re-Entrant Task possible proposal: Define a new Verilog key word: taskr?
Have task and taskr keywords, similar to case, casez, casex keywords.
Each time the taskr is called, a new copy of run-time variables is
created and maintained for each taskr invoked
Alternate idea suggested by Karen Pieper:
Make optional "automatic" additions to declarations (to allow stackable
variables)
automatic variables are stacked - some variables are local and some are
stacked.
This proposal would not require a new "taskr" keyword.
Cliff-note: Karen's idea may actually be a separate proposal. Adoption of
Karen's idea in addition to a taskr would introduce three types of tasks:
(1) task - All variables are static and each new call to an already running
task will overwrite the same static variables (this is how Verilog is
specified and how it currently behaves)
(2) taskr - All variables are local (automatic?) to the taskr that was
called. Multiple calls to the same taskr will not overwrite variables from
a previously invoked and already running taskr. (Cliff-Note: I believe most
Verilog users erroneously believe this is how Verilog currently performs
since this is how programming language subroutines behave).
(3) task with some variables declared to be automatic - This would behave
exactly like task(1) above except that certain variables could be declared
as "automatic," or local to the task. (A hybrid of the two above methods).
A task(1) would behave exactly like a taskr(2) if all of the variables in
the task had been declared to be automatic.
I still believe that taskr(2) is a valuable addition to Verilog since it is
a shorthand for task with automatics and does not require the user to add
extra declaration verbiage for a task that was intended to run with local
variables. The unique taskr name also sets it apart from the existing
Verilog task and allows one to easily scan Verilog code without having to
look for the potential existence of an automatic declaration.
BTF - Please comment!
---------------
B05 Notes - Verilog Configurations
B05: Cliff to send and then re-word
Abstract: What Are Configurations? A configuration file describes which
modules (source files) will be used during simulation.
Configurations can contain:
- all behavioral models
- all gate-level (structural) models
-a mix of behavioral and structural models
Different configuration files are used to increase testing productivity by
allowing slower gate-level models to be simulated with faster behavioral
models in a larger design; thereby improving simulation efficiency.
One example of mixing gate and behavioral instances in the same design is
instantiating four identical adders into a model, 3 behavioral adders, 1
gate-level adder.
The Cadence approach (not in the IEEE-1364 Standard)is the inclusion of
`uselib compiler directives in the source code, which requires multiple
source files for multiple configurations. I believe modification of a
source file is an undesirable solution.
Proposal: Standardize the following command switches:
-f to call command files and source listing files
-v to specify library files
-y to specify library directories
+libext+.v to specify file extensions
// to add comments to command.f files
/* */ to add multi-line commants to command.f files
Similarly, we may want to add command-line switches for configuration
purposes? These could be typed on the command line or perhaps (more common)
placed in a command file (<configuration>.f)
Two possible proposals (I am leaning towards Use Model #2):
Use Model #1:
+uselib+<source_directory_or_file>[+<optional_libext>]=<instance_name>[+
<instance_name>]*
+uselib+/proj/gates/adder.v=top.i2
+uselib+/proj/vlog+libext+.v+.p=top.i1+top.i3+top.i4
Use Model #2:
+config=<instance_name>[+<instance_name>]*=<source_directory_or_file>[+<opti
onal_libext>]
All of the examples below are intended to give the same result:
+config=top.i2=/proj/gates/adder.v
+config=top.i1+top.i3+top.i4=/proj/vlog/adder.v
-or-
+config=top.i2=/proj/gates/adder.v
+config=top.i1+top.i3+top.i4=/proj/vlog+libext+.v+.p++
(the +.p++ are ignored in this example)
-or- // (typical usage)
-y /proj/vlog // (picks up i1, i3 and i4 instances)
+libext+.v
+config=top.i2=/proj/gates/adder.v
-or- // (typical usage)
+config=top.i2=/proj/gates/adder.v
-y /proj/vlog // (picks up i1, i3 and i4 instances)
+libext+.v
Exact usage and placement of the ='s and +'s is not too important to me.
Whatever makes the parsing of the command options easy for EDA vendors
would probably be fine with me.
The above syntax still may need help! We should be seeking for a
simple/consistent syntax to address this issue. We should avoid a complex
VHDL-like solution to configurations.
I have had many Verilog students ask if environmental variables could be
used in .f files. I believe it is a good idea (except for PC-Verilog
compatibility?) Comments??
Regards - Cliff
//********************************************************************//
// 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:41 PDT
and
sponsored by Boyd Technology, Inc.