Re: [sv-bc] minor wire issues

Hi, Shalom -

I have read your comments and Brads follow-on comments. My thoughts below.

At 02:42 AM 7/2/2007, you wrote:
>Hi,
>
>A few minor issues related to tri's and uwire's.
>
>1. 6.8.1 has the example: tri [15:0] busa; // a three-state 16-bit bus
>This is not accurate. tri is exactly the same as wire. It may or may 
>not be three-state.

You are correct, but the example was trying to show a declaration 
where the user intended the net to be used as a 3-state net, and for 
that reason, I believe any changes or "clarifications" to the comment 
would require more explanation and possibly cause more confusion than 
it is worth. I recommend that we make no change to the comment.

Personally, I have not declared any "tri" nets in over a decade. I 
just declare everything as wire and I know that I am using a resolved type.

Sharp eye, but probably not worth a change here.

>2. 6.10.1 describes tri and wire.
>6.10.2 describes wired-and and wired-or nets.
>6.10.3 describes triregs.
>6.10.4 describes tri0 and tri1.
>6.10.5 describes uwires.
>
>I think uwires are closer to plain wires than any of those other 
>variants, so I think the uwire sub-clause should immediately follow 
>6.10.1 instead of being several sub-clauses distant.

Agreed - I like your re-ordering. I will have more to say about uwire 
in a separate email.

>3. 10.3.4 Continuous assignment strengths
>
>The driving strength of a continuous assignment can be specified by 
>the user. This applies only to assignments
>
>to scalar nets of the following types:
>
>wire tri trireg
>
>wand triand tri0
>
>wor trior tri1
>
>This omits uwires. In fact, it would be easier to write
>
>This applies only to assignments to scalar nets, except of type 
>supply0 and supply1.

I like it. It is a nice simplification.

>4. Annex L: vpiTri has the comment /* three-state net */. This is 
>not accurate. tri is exactly the same as wire. It may or may not be 
>three-state.

I would not change this for the same reasons as point #1 above. 
Again, you are technically correct, but I believe there is value in 
leaving this comment as is.

>Shalom Bresticker
>
>Intel Jerusalem LAD DA
>
>+972 2 589-6852
>
>+972 54 721-1033

Regards - Cliff

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


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