Re: [sv-bc] MERGE REVIEW draft 2: Chapter 6

Shalom writes --

>Finally, I saw one place in the BNF where 'reg' is required twice
>instead of logic, in A.5.2: 

This is the topic of

   http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001368

-- Brad

[ In reply to http://www.eda-stds.org/sv-bc/hm/5824.html . ]

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, April 16, 2007 1:30 AM
To: Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] MERGE REVIEW draft 2: Chapter 6

Brad,

> 6.3 -- "Nets cannot be written by procedural statements. ...  A net 
> cannot be procedurally assigned."  Is there a difference between these

> two?

[SB] Probably not.


> 6.3 -- "Variables can be written by one continuous assignment or one 
> port."  I guess this means by an output port, but isn't that 
> necessarily a continuous assignment?  What's the need for adding "or 
> one port"?

[SB] I also see no need.


> 6.5 -- "The keywords logic and reg are equivalent types (see 6.20.2 
> for details on type equivalence)."  A keyword is not a type.  I think 
> that the 'logic' and 'reg' data types are at least matching, not 
> merely equivalent, and are perhaps even identical types.  I see no 
> details about this issue in the cross-referenced 6.20.2.

[SB] I agree (except for the few lexical restrictions on reg), but this
goes back to 1800-2005. Twice it says there that they are equivalent and
references the equivalence rules, in 4.3.2 and in 6.1. 27.14 Detail (s)
says, "SystemVerilog treats reg and logic variables as equivalent in all
respects."

Also, in 15.14.2, there is an example with the following sentence that
probably should be reworded: 
"The driven value of nibble is 4'b0xx1, regardless of whether nibble is
a reg or a wire."

Finally, I saw one place in the BNF where 'reg' is required twice
instead of logic, in A.5.2:

udp_output_declaration ::=
  { attribute_instance } output port_identifier
| { attribute_instance } output reg port_identifier
                                             [ = constant_expression ]

udp_reg_declaration ::= { attribute_instance } reg variable_identifier


> 6.6.1 -- "specified by the lsb" Unnecessary italics.

[SB] Also, "the msb" in the previous line, "the" should not be in
italics.

 
> 6.6.1 -- "Vector nets and vectors of reg, logic and bit types shall be
> treated as
> unsigned quantities, unless declared to be signed or is connected to a
> port that is declared to be signed (see 22.8.3)."  Again there's a
> mixing of kind and type.  The type of a net could be logic vector.
> Also, how does connecting a vector to a signed port cause it to be
> treated as a signed quantity?  There's no example using a port
> connection in the examples that immediately follow.  And there's
> nothing
> about this in the cross-referenced section, which regards parameter
> value assignments.

[SB] This comes from 1364-2005, section 4.3.1, where the original text
is, "Vector nets and regs shall be treated as unsigned quantities,
unless the net or reg is declared to be signed or is connected to a port
that is declared to be signed (see 12.2.3)."

The cross-reference there is incorrect also. The correct reference in
1364 is 12.3.3, where it says,

"The signed attribute can be attached either to a port declaration or
the corresponding net or reg declaration or to both. If either the port
or the net/reg is declared as signed, then the other shall also be
considered signed.

Implicit nets shall be considered unsigned. Nets connected to ports
without an explicit net declaration shall be considered unsigned, unless
the port is declared as signed."


> 6.18 and 6.18.5, "local constant"?   Maybe it's OK, but worth having a
> discussion about this newly added terminology, that is used only twice
> in the draft LRM.

[SB] This term is used in 1800-2005 only once, in the section
corresponding to 6.18.5 here. I don't like it, although 1364 is
responsible for the term 'local parameter'.

Thanks,
Shalom

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.