RE: Verilog Synthesis draft 2.0 // Comments


Subject: RE: Verilog Synthesis draft 2.0 // Comments
From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Mon Feb 25 2002 - 06:32:50 PST


Ben:
 
See my embedded comments.


Two sets of commemts: grammar + content.

1. grammar/rules/etc:
A. You need 2 spaces after a period. // throughout document
 
[J. Bhasker] i am going to let IEEE editors do this later based on their style preference.

B. Document is inconsistent in teh use of "," before the "but". 1.3 Terminology
The word should is used to indicate
that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain
course of action is deprecated but not prohibited (should equals is recommended that). // no comma

A synthesis tool shall not be required to provide an interpretation for every construct
that it accepts, but only for those for which an interpretation is speci.ed by this standard. // with comma
//I think that you need the comma

  Under 3. Definitions
  from: "Terms used within this standard but not defined in this clause are assumed to be from the Language Reference Manual (see Clause 2)."
to : "Terms used within this standard, but not defined in this clause, are assumed to be from the Language Reference Manual (see Clause 2)."

[J. Bhasker] - done

C. Sentence structure:
from: "Supported: RTL synthesis shall interpret a construct, that is, map the construct to hardware"
to: "Supported: RTL synthesis shall interpret and map the construct to hardware.

[J. Bhasker] done.
 
D. 5.6 Modeling Read-Only Memories (ROM)
Change from: The rom_block attribute shall be used to identify the variable which models the ROM."
TO: The rom_block attribute shall be used to identify the variable that models the ROM."

[J. Bhasker] done.
 
E. 5.6.2 Using two-dimensional array with data in initial statement
FROM: "It may other synthesizable statements, such as for loop statements,.."
TO: "It may contain other synthesizable statements, such as for loop statements,

[J. Bhasker] done.
 
Content
under 3.0
"A metalogical value is either an x or a z."
Actually, the "z" is high impedence. The only exceptiuon where 'x' and 'z' are metalogical is in the casex and casez. From lrm 9.5.1 Case statement with don’t-cares
"Two other types of case statements are provided to allow handling of don’t-care conditions in the case comparisons. One of these treats high-impedance values (z) as don’t-cares, and the other treats both high-impedance and unknown (x) values as don’t-cares."
I suggest that we change
from: j) metalogical
A metalogical value is either an x or a z.
to: j) metalogical
A metalogical value is either an x or a z in casex and casez, or an x in the right-hand side of assignment to signify a don't care value (see 5.5 Support for values x and z).

[J. Bhasker] The intent here was only to define what a metalogical value is as the term is used in the rest of the text.

4. Verification Methodology
..."This also implies that the port list of the synthesized result must be the
same as the original model - ports cannot be added or deleted during synthesis."
We discussed "probe" on wire or reg, to preserves internal nets for probing causing them to appear as ports at the top level. The "probe" pragma is not on the list, and that one DOES add PORTS on the netlist.
[J. Bhasker] From my notes, it appears that we did not close on this topic, as we could not define what was meant by "top level". Let me know if this is not consistent with what we had decided in the meeting.

4.1 Combinational Logic Verification
always A = #5 ~A ; // no sensitivity list in this example
Change to: always @* A = #5 ~A ;
[J. Bhasker] Done.

5.3 Modeling level-sensitive storage devices
No mention is made for the following:
always @ (ENABLE or D)
if (ENABLE)
Q = D;
else Q = Q;
// Looks like a non-latch, but is a latch

[J. Bhasker] According to the rules listed, Q is not a latch.

5.4 Modeling three-state drivers
Need 2 more models with an always
always @ (IN)
begin
if (!enb) out <= 'bz else q;

// this may not be the best style, but it is ok.
Also
always @ (posedge CLOCK or posedge SET)
if (SET)
OUT <= 1’b1;
else if (!enb) out <= 'bz;
else OUT <= DIN;
// Actually this infers 2 FFs, one for the enb control, and one for the out.
[J. Bhasker] Done.


6.1.4 Miscellaneous Attributes
The black box exmple is very poor.
Use this instead. Note: LPM is a general spec, and is not restricted to Altera.

We may also want to show this a la 2001 interface

module add2 (
input [7:0] dataa,
input [7:0] datab,
input cin,
output [7:0] result,
output cout,
output overflow) /* synthesis black_box
    lpm_width = 8
    lpm_direction = "ADD"
    one_input_is_constant = "NO"
    lpm_hint = "SPEED"
    lpm_type = "LPM_ADD_SUB"
   */ ;
endmodule
[J. Bhasker] Done.

6.1.4 Miscellaneous Attributes
synthesis, keep
The following sentence is anbiguous and not clear. What does " no optimizations to occur across the specified reg boundaries" mean?
"The presence of the attribute shall cause no optimizations to occur across the speci.ed reg (which has been
inferred as an edge-sensitive storage device) boundaries. This attribute does not apply if the reg has not been
inferred as an edge-sensitive storage device."
[J. Bhasker] Can you suggest a better wording?

- bhasker




This archive was generated by hypermail 2b28 : Mon Feb 25 2002 - 06:39:01 PST