From: Anders Nordstrom (andersn@nortelnetworks.com)
Date: Fri Jul 16 1999 - 10:58:31 PDT
<x-html>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Team,
<p>Enclosed are the open items we have to work on on Monday.
<br>Please start looking at them right away so we have a chance of going
through them at the
<br>call. I have not yet pulled together all the files for BE87 - re-entrant
task update since
<br>there has been quite a lot of discussion on that one already.
<p>I have not included BE01, BE40, BE49, BE68 and BE69 which Cliff Cummings
are
<br>working on as part of finishing the BNF.
<p>The following items are still open:
<br>
<ul>
<li>
BE88 generate statement errata from Tom Fitzpatrick</li>
<li>
BE87 re-entrant task errata from Tom Fitzpatrick.</li>
<li>
B31 Specification of Sized Constants</li>
<li>
B33 Parameter Type Declarations</li>
<li>
BE71 Port connections
- Stefen to write proposal</li>
<li>
BE72 Race conditions
- Adam to write proposal</li>
<li>
BE81 Register terminology</li>
<li>
BE90 Bit lengths from expressions</li>
</ul>
We are getting really close to the end now. We have finished 40 enhancement
<br>requests and 81 errata!!!! Only these few items to go.
<br>Try to make it for the call on Monday July 19 so we can complete it
all.
<p>Cheers,
<p>
Anders
<br>
<br>
</body>
</html>
</x-html>
<x-html>
<HTML>
<HEAD>
<TITLE> B31 </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<BR>
<HR SIZE=5 NOSHADE>
<H2> B31 - Specification of sized constants </H2>
<TABLE BORDER COLS=2 WIDTH="75%" >
<TR><TD>
Section: </TD><TD> TBD
</TD></TR><TR><TD>
Date Submitted: </TD><TD> 980407
</TD></TR><TR><TD>
Requestor: </TD><TD> Adam Krolnik
</TD></TR><TR><TD>
Status: </TD><TD> Rejected by BTF 990419
</TD></TR><TR><TD>
Analyzed by: </TD><TD> BTF Team
</TD></TR><TR><TD>
Synthesizable: </TD><TD> Yes
</TD></TR>
</TABLE>
<H3> Details </H3>
Motivation: <BR>
Currently the only acceptable way to define the size of a constant is with
a constant number, or a preprocessor substitution. Allowing parameters would
at least bring numbers to the abilities of ports and other sized data types.
Please consider allowing parameters (at the least) to define the length of a constant. Should there be other ways to specify the size of a value? Should there be a restriction that the size be constant?
An Example
<PRE>
module tst;
`define length 4
`define width 6
parameter size = `len * `wid;
reg[`width:1] a, out;
reg[`length*`width:1] b;
initial begin
$display("Size is %0d.", size);
b = size 'b0; // Using parameter to specify size.
end
always @(clk) begin
{out, b} = {b, a};
end
endmodule
</PRE>
Proposed text:
To section 2.5.1 "Integer constants" third paragraph, second sentence, which
reads:<BR>
"It [size constant] shall be specified as an unsigned decimal number."
Replace it with:
"It [size constant] shall be specified as an unsigned decimal number or a parameter."
BNF:
<PRE>
size ::=
unsigned_number
| parameter_identifier
<p> Adam Krolnik
Verification Engineer
Cyrix - NSM.
Richardson TX 75085
</PRE>
<HR SIZE=5 NOSHADE>
</BODY>
</HTML>
<p></x-html>
<x-html>
<HTML>
<HEAD>
<TITLE> B33 </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<BR>
<HR SIZE=5 NOSHADE>
<H2> B33 - Parameter Type Declarations </H2>
<TABLE BORDER COLS=2 WIDTH="75%" >
<TR><TD>
Section: </TD><TD> A.2 & 3.10
</TD></TR><TR><TD>
Date Submitted: </TD><TD> 980312
</TD></TR><TR><TD>
Requestor: </TD><TD> Steve Meyer
</TD></TR><TR><TD>
Status: </TD><TD> Submitted
</TD></TR><TR><TD>
Analyzed by: </TD><TD> BTF Team
</TD></TR><TR><TD>
Synthesizable: </TD><TD> Yes
</TD></TR>
</TABLE>
<H3> Details </H3>
I propose changing parameter declaration statements to allow normal
reg range and signed declaration keywords. If feature has already been
proposed, just ignore this. Some examples (I am not sure if I am using latest
syntax):
<PRE>
parameter signed [3:0] mux_selector = 0;
paramater signed [0:3] mux_selector = 0; // only different if selects allowed
parameter real r1 = 3.5e17;
parameter p1 = 13'h7e;
parameter [31:0] dec_const = 1'b1; // valued converted to 32 bits
</PRE>
Notes: <P>
1) For backward compatibility, parameter declarations without range or type
allowed using current width determined by right hand side expression
width still permitted.
2) Parameters declared with ranges can possibly be stored more efficiently.
Solves problem when constants are assigned initial (or # param
or defparam) values using small decimal constants.
3) Makes Verilog 98 compatibible with Verilog-AMS.
4) I think selects from parameters should be explicitly allowed by standard
following XL. In fact, every simulator needs to support selects from
parameters or else models in Thomas-Moorby book will not run
(i.e. dec_const[9] or dec_const[13:5]).
/Steve
<PRE>
-- Steve Meyer Phone: (415) 296-7017 Pragmatic C Software Corp. Fax: (415) 296-0946 220 Montgomery St., Suite 925 email: sjmeyer@crl.com San Francisco, CA 94104 </PRE>Steve,
At the last 1364 WG meeting we were discussing and voting on the attached proposal. It was not approved because the algorithm for type conversion was not defined. Could you help with the wording from the Verilog AMS LRM? We are interested in passing this enhancement but we need some help.
Thanks,<BR> Anders
You have my old email address. New one is sjmeyer@pragmatic-c.com. I have set reply to new one.
Latest AMS LRM I have seen (1.30) only allows typed parameters and only real and integer but one dimensional arrays of parameters are allowed and needed for analog operatorors such as laplace. The Antrim AMS simulator that uses Cver as digital event engine and elaborator runs digital P1364 code without change (customers do not want to change their digital code to run on AMS simulator) so it allows both old style without type declaration parameters and new style with type declaration.
Algorithm for parameter conversion is same as for procedural assignment (automatic conversion between real and integer left hand side determines width and type etc.). I think AMS LRM state somewhere that conversion rules are same for assignment and I think all that is needed is to add cross reference to section defining procedural assignment conversion rules in new Verilog 99 LRM. Also I think there is already a statement somewhere in LRM say pound parammeter follow (are the same as) assignments.
I think XL uses same procedural assignment rules for parameters with type and/or range declared.
Cver also uses rule that for old style parameters the type is determined from the parameter statement right hand side expression and then that left hand side type is used to make conversions for defparams and pound parameters. This is needed for AMS because users want to be able to use parameters in both analog and digital blocks.
Have I answered your question? <BR> /Steve
<H3> Proposal </H3>
In section A.2 on page 595 and Syntax 3-4 on page 25, change the syntax for param_assignment to: <PRE> param_assignment ::= parameter_identifier [signed] [range] = constant_expression </PRE> On page 26 before section 3.11, add the following examples: <PRE> parameter signed [3:0] mux_selector = 0; parameter p1 = 13'h7e; parameter [31:0] dec_const = 1'b1; // valued converted to 32 bits </PRE>
<HR SIZE=5 NOSHADE> </BODY> </HTML>
</x-html> <x-html> <HTML> <HEAD> <TITLE> BE71 </TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <BR> <HR SIZE=5 NOSHADE> <H2> BE71 - Section 5.6.6 Port connections </H2>
<TABLE BORDER COLS=2 WIDTH="75%" > <TR><TD> Section: </TD><TD> 5.6.6 </TD></TR><TR><TD> Date Submitted: </TD><TD> 980313 </TD></TR><TR><TD> Requestor: </TD><TD> Adam Krolnik </TD></TR><TR><TD> Status: </TD><TD> Submitted </TD></TR><TR><TD> Analyzed by: </TD><TD> TBD </TD></TR> </TABLE>
<H3> Details </H3>
Section 5.6.6 "Port connections" describes the seldom seen syntax for specifying a port with separate internal and external names.
Why is this text in this section? Why is there no reference to 5.6.6 and this available syntax in section 12.3?
I propose that this orphan port syntax description be moved to it's correct location (section 12.3). I.e. The Third paragraph should only read "Port connection rules are given in 12.3.7." <BR> [And possibly should be joined to the first paragraph.]
Section 12.3 should include an example of a module with this specific syntax and an example of it being instantiated.
<PRE> Adam Krolnik Verification Engineer Cyrix - NSM. Richardson TX. 75085 </PRE>
<HR SIZE=5 NOSHADE> </BODY> </HTML>
</x-html> <x-html> <HTML> <HEAD> <TITLE> BE72 </TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <BR> <HR SIZE=5 NOSHADE> <H2> BE72 - Section 5.5 Race conditions </H2>
<TABLE BORDER COLS=2 WIDTH="75%" > <TR><TD> Section: </TD><TD> 5.5 </TD></TR><TR><TD> Date Submitted: </TD><TD> 970929 </TD></TR><TR><TD> Requestor: </TD><TD> Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk) </TD></TR><TR><TD> Status: </TD><TD> Submitted </TD></TR><TR><TD> Analyzed by: </TD><TD> TBD </TD></TR> </TABLE>
<H3> Details </H3> <PRE>
module EXP_143; reg q; // comment out only one of the following two lines: wire p; assign p=q; // wire p=q; initial begin #1 $display("1st simulation cycle: q",q," p",p); #0 $display("2nd simulation cycle: q",q," p",p); end // initial #1 initial begin // this code based on that on p5-4, Oct P1364 q=1; #1 q=0; $display("1st: q",q," p",p); #0 $display("2nd: q",q," p",p); end // initial begin initial begin #1 $display("1st simulation cycle: q",q," p",p); #0 $display("2nd simulation cycle: q",q," p",p); end // initial begin endmodule // EXP_143 With wire p=q; only commented out $verilog -q experiment.143.cv 1st simulation cycle: q1 p1 1st: q0 p1 1st simulation cycle: q0 p1 2nd simulation cycle: q0 p1 (p is still 1) 2nd: q0 p0 2nd simulation cycle: q0 p0 </PRE>
The example code in section 5.5 "Race conditions" is at fault. <BR> It states that the display immediately following the q=0 <BR> assignment could show p as either 1 or 0. <BR> This code shows that in fact, p does not become 0 until <BR> partway through the 2nd simulation cycle in the same timestep, <BR> hence it is impossible for the first display to see p=0. <BR> This is because of the implicit #0 net delay. <BR> <PRE> With wire p; assign p=q; only commented out $verilog -q experiment.143.cv 1st simulation cycle: q1 p1 1st: q0 p0 1st simulation cycle: q0 p0 (p is already 0) 2nd simulation cycle: q0 p0 2nd: q0 p0 2nd simulation cycle: q0 p0 </PRE> Here, without the implicit #0 net delay, p becomes 0 <BR> within the 1st simulation cycle.
<HR SIZE=5 NOSHADE> </BODY> </HTML>
<p></x-html> <x-html> <HTML> <HEAD> <TITLE> BE81 </TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <BR> <HR SIZE=5 NOSHADE> <H2> BE81 - Register terminology </H2>
<TABLE BORDER COLS=2 WIDTH="75%" > <TR><TD> Section: </TD><TD> all </TD></TR><TR><TD> Date Submitted: </TD><TD> 980914 </TD></TR><TR><TD> Requestor: </TD><TD> Stuart Sutherland (stuart@sutherland.com) </TD></TR><TR><TD> Status: </TD><TD> Submitted </TD></TR><TR><TD> Analyzed by: </TD><TD> TBD </TD></TR> </TABLE>
<H3> Details </H3>
There is a discrepancy in terminology between the HDL sections and the PLI sections of the LRM, which the PLI task force feels would be best corrected in the HDL portion.
The HDL lumps the keywords reg, integer, time and real into the "register" data type class. I'm sure we have all dealt with the confusion the term "register" causes when hardware designers try to learn Verilog--I won't belabor the issue.
In the PLI, the VPI part of the standard documents all Verilog objects and their relationships with other objects. The VPI does not use the term "register". It treats "reg" as a unique object type, and then has a class of objects called "variables" which includes integer, time and real (pages 537 and 538 of the 1364-1995 LRM)
Please consider making the same distinction in the HDL sections of the LRM that are already in the PLI sections. Section 3 almost makes the distinction already. Section 3.2.2 (using the 1364-1995 numbering) deals solely with the reg data type, and section 3.9 deals with the integer, time and real types. It should be a relatively minor change to Section 3 to eliminate the term "register" as a data type, and to distinguish between "reg" and "variables". A global search of the remaining sections of the LRM would simply replace "register" with the appropriate "reg", "variable" or "reg or variable" terms.
A note could be added to section 3 explaining that in previous versions of the Verilog standard, the term "register" was used to encompass both the reg and variable types, but that the term is no longer used as a Verilog data type because Stu Sutherland got tired of explaining to new Verilog users that a data type register did not imply a hardware register (or words to that effect) ;)
Please discuss this suggestion as soon as possible and let us know your thoughts. The PTF is currently working on adding multi-dimensional arrays to the VPI diagrams, and we would like to use consistent terminology as the HDL sections of the standard.
Thanks,
Stu <PRE> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL Inc. stuart@sutherland.com 22805 SW 92nd Place phone: 503-692-0898 Tualatin, OR 97062
www.sutherland.com
Specializing in Verilog HDL consulting and training. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ </PRE>
<HR SIZE=5 NOSHADE> </BODY> </HTML>
<p></x-html> <x-html> <HTML> <HEAD> <TITLE> BE88 </TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <BR> <HR SIZE=5 NOSHADE> <H2> BE88 - Comments on Generate Statement </H2>
<TABLE BORDER COLS=2 WIDTH="75%" > <TR><TD> Section: </TD><TD> TBD </TD></TR><TR><TD> Date Submitted: </TD><TD> 990609 </TD></TR><TR><TD> Requestor: </TD><TD> Tom Fitzpatrick </TD></TR><TR><TD> Status: </TD><TD> Submitted </TD></TR><TR><TD> Analyzed by: </TD><TD> TBD </TD></TR> </TABLE>
<H3> Details </H3>
Hi Gang,
I'd like to make a couple of friendly ammendments to the Generate proposal.
1) I propose that the genvar declaration be brought inside the generate-endgenerate block. Since genvars are only used for controlling the instantiation of things prior to runtime, I think it makes sense to limit their scope as well. That way, we don't have to worry about the behavior of genvars being shared across blocks. Consider: <PRE> genvar i;
generate for(i=0;i<4;i=i+1) foo f(a,b,c); endgenerate
generate if(i==4) bar b(d,e,f); endgenerate </PRE> This is a bit of a contrived example, but I think it illustrates the point. I'd much rather require that these have to be in a single generate block in order to have i persist after the for loop <PRE> generate genvar i; for(i=0;i<4;i=i+1) foo f(a,b,c); if(i==4) bar b(d,e,f); endgenerate </PRE> I think this is a lot cleaner and makes it easier to debug potential problems if everything that uses a particular genvar is forced to be local inside a single generate block.
2) The current proposal states that the indexed name of instances within a generate-for loop is inferred from the fact that it's inside a loop. I'd like to make it explicit.
Instead of: <PRE> parameter SIZE = 2; genvar i, j, k, m; generate for (i=0; i<SIZE+1; i=i+1) begin M1 N1(); // instantiates N1[i] for (j=0; j<SIZE; j=j+1) begin M2 N2(); // instantiates N2[i][j] for (k=0; k<SIZE; k=k+1) begin M3 N3(); // instantiates N3[i][j][k] end end if (i>0) for (m=0; m<SIZE; m=m+1) begin M4 N4(); // instantiates N4[i][m] end end endgenerate
I'd like to see:
parameter SIZE = 2; generate genvar i, j, k, m; for (i=0; i<SIZE+1; i=i+1) begin M1 N1[i](); // instantiates N1[i] for (j=0; j<SIZE; j=j+1) begin M2 N2[i][j](); // instantiates N2[i][j] for (k=0; k<SIZE; k=k+1) begin M3 N3[i][j][k](); // instantiates N3[i][j][k] end end if (i>0) for (m=0; m<SIZE; m=m+1) begin M4 N4[i][m](); // instantiates N4[i][m] end end endgenerate </PRE> This particularly makes it clear when differentiating between a generated "array" of instances and a generated "choice" of instances.
3) We are referring to a set of for-generated instances as an "array", since we use the "[]" notation. However, these aren't really arrays. The "[k]" notation is simply a naming convention, which means that there's no problem of using non-contiguous index values for a set of instances. The problem is that, if we want to have any hope of these actually becoming real arrays of instances, then they MUST be contiguous. Allowing for the possibility of sparse arrays of instances will kill the potential performance of the simulator. This is really why VHDL uses the "for i in 0 to 3" notation for specifying generate loops.
The equivalent of this for Verilog would be to require that the initial clause and the terminating clause of the generate-for loop must use the same genvar, and the iteration clause must be either i=i+1 or i=i-1. I think it may be cleaner to use the "+:" and "-:" notation that we've agreed on for indexed part selects. Something like: <PRE> generate genvar i; for (i=0+:SIZE) // for (i=0;i<SIZE;i=i+1) ... endgenerate </PRE> You could still use the generate conditional and case to change what gets intantiated for each pass through the loop, but you must instantiate something in each pass of the loop.
4) The value inside the "[]" should be restricted to simple digits. There is no difference in Verilog between "1234" and "12_3_4", but from a "names" perspective, these are different. To eliminate any parser issues, we should limit index values to the BNF-ish {digit}
<PRE> --------------- Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc. RTL Verification Flow/Product Engineering 270 Billerica Rd. Design and Verification R&D Chelmsford, MA 01824 x6438 (978)446-6438
</PRE>
<H3> Proposal </H3>
<HR SIZE=5 NOSHADE> </BODY> </HTML>
</x-html> <x-html> <HTML> <HEAD> <TITLE> BE90 </TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <BR> <HR SIZE=5 NOSHADE> <H2> BE90 - Bit lengths resulting from expressions </H2>
<TABLE BORDER COLS=2 WIDTH="75%" > <TR><TD> Section: </TD><TD> TBD </TD></TR><TR><TD> Date Submitted: </TD><TD> 990607 </TD></TR><TR><TD> Requestor: </TD><TD> Tom Fitzpatrick </TD></TR><TR><TD> Status: </TD><TD> Submitted </TD></TR><TR><TD> Analyzed by: </TD><TD> TBD </TD></TR> </TABLE>
<H3> Details </H3>
The width of a multiplication in the de facto standard Verilog-XL is the same as the other binary operators: max(L(i),L(j)). This should be fixed in the spec.
Note that multiplication without losing any overflow bits is still possible simply by assigning the result to something wide enough to hold it.
Even if it were decided that XL is wrong and the spec is right, there is still a problem with the width for the power operator. Consider the innocuous looking case of 2**2. The value of this expression would require 8 times more memory than the processor can even address (e.g. 32 Gigabytes for a machine with 32 bit integers). The literal '2' is 32 bits wide, and with the exponentiation in the width, this blows up into a huge width for the result.
<PRE> --------------- Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc. RTL Verification Flow/Product Engineering 270 Billerica Rd. Design and Verification R&D Chelmsford, MA 01824 x6438 (978)446-6438 </PRE>
<HR SIZE=5 NOSHADE> </BODY> </HTML>
</x-html>
Attachment Converted: "C:\Documents and Settings\stefen\Application Data\Qualcomm\Eudora\andersn9.vcf"
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:29 PDT
and
sponsored by Boyd Technology, Inc.