[sv-ac] ballot result on 1900

From: John Havlicek <john.havlicek_at_.....>
Date: Tue Jan 08 2008 - 04:41:19 PST
Hi Folks:

Lisa voted "no" on 1900, but I'm not sure the reason given
qualifies according to our operating guidelines.

See the results below.

We will discuss how to proceed in today's meeting.

J.H.

----------------------------------------------------------------------------------
Ballot on Mantis 1900

- Called on 2007-12-31, final ballots due by 2008-01-07 T 23:59-08:00.

yv[xxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
yv[xxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
 n[--------------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
yv[xxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
 t[xx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
yv[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
 v[xxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
 n[----------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
 n[-------x------------x--xxx.....................] Joseph Lu (Altera)
 v[xxxxxxxxxxxxxxxxx..............................] Johan Martensson (Jasper)
 n[-------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
nv[xxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
yv[xxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
 n[-----x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
yv[xxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
yv[xxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
   |----------------------------------------------- attendance on 2007-12-18
 |------------------------------------------------- voting eligibility for this ballot
|-------------------------------------------------- email ballots received

        Legend:
                x = attended
                - = missed
                r = represented
                . = not yet a member
                v = valid voter (2 out of last 3 or 3/4 overall)
                n = not a valid voter
                t = chair eligible to vote only to make or break a tie


----------------------------------------------------------------------------------
Rationale for Negative Vote

[LP]

I need to vote "no" simply because our internal review of this is not
complete. I hope to have feedback by this time next week.


----------------------------------------------------------------------------------
Friendly Amendments

[YF]

page 7:
checker_instantiation ::=3D
checker_identifier name_of_instance ([list_of_port_connections]) ;

should be same as page 32:
checker_identifier name_of_instance ([list_of_checker_port_connections])
;


also, on page 23 it is written:
always_check @clk
a <=3D b && $future_gclk(c);
The equivalent form after rewriting is:
assign a =3D $changed_gclk(clk) ? $past_gclk(b) && c : $past_gclk(a);


I think it should be added that there is an assumption that all those
signals do not change between edges of the global clock , otherwise in
simulation a bad definition of global clock (that is a definition of an
event which isn't necessarily the fastest one) means the above isn't
equivalent (since if you look at the value of "a" thus by the assign the
values of  "clk" or "c" between edges of the global clock you can see
different values than those in the actual edge of the global clock).

[TT]

16.18.1 Overview

"These verification blocks need sometimes also to contain . . ."
Change to
"These verifcation blocks may also need to contain . . ."


" Checkers may assign values to their formal arguments, treating them as 
output arguments"

If this is true, will the new values be observed by the calling scope?



" . . . but the data types of checker formal arguments are not necessary 
limited ..."

Change "necessary" to "necessarily"


----------------------------------------------------------------------------------
Comments 

[SB]

I have NOT studied the proposal, just glanced at it, but I did notice one thing that bothers me.

The top of page 9 says,

"Checkers may be instantiated both inside and outside of the procedural code. Connections to checker formal arguments can be created by similar means to module ports (see 16.12):

 Positional connections by port order.
 Named port connections using fully explicit connections.
 Named port connections using implicit connections.
 Named port connections using a wildcard port name.

An implicit .* port connection is semantically equivalent to a default .name port connection for every port declared in the instantiated module with two exceptions. First, if an instantiation uses a .name port connection, it is assumed that the intent is to connect the port, and therefore any default value assigned to that port is not used. In this case, if no connection is made and a default value exists, an error will still occur. However, if .* is used and no port connection is found but the declaration has a default value, the default value will be used, the intent being that if default values are specified, they should be used if no connection exists (see 22.3.2.4 for more information)."

First, the xref at the beginning is wrong.

Second, the xref at the end is referring to 'more information' that is added by Mantis 1619, the SV-BC proposal for module port defaults.

Yet the proposal also lists at the beginning in the Objectives section as a current limitation, "Default values for ports are not available". On the other hand, the proposal does rely on Mantis 1681, 1648, 1728, and 1682, of which 1682 appears to be in a less advanced state than 1619. (By the way, shouldn't 1681 add $global_clock to 19.12?)

This paragraph is also more-or-less copy-pasting a paragraph from 1619. However, that paragraph in 1619 has been revised. If to quote it, then take the updated version.

Also, the first paragraph is grammatically awkward.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 8 04:42:56 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 04:43:15 PST