Subject: $sv-ec Minutes of SV-EC on September 4, 2002
From: Stefen Boyd (stefen@boyd.com)
Date: Mon Sep 09 2002 - 12:46:46 PDT
Thanks to Zeev Kirshenbaum and Francoise Martinolle for taking
minutes. I've tried to merge theirs and my scattered notes. We
covered a lot of ground, so review carefully.
Thanks,
Stefen
SV-EC Meeting Minutes
4 September 2002
(--a---) Adam Krolnik (LSI Logic)
(---a-a) Alec Stanculescu (Fintronic)
(a-aaaa) Cliff Cummings (Sunburst)
(-aaa--) Dave Kelf (Co-Design)
(aaaaa-) David Smith (Synopsys)
(-aaa-a) Dennis Brophy (ModelTech)
(---aaa) Francoise Martinolle (Cadence)
(aa-aa-) Heath Chambers (HMC)
(aaaaaa) Karen Pieper (Synopsys)
(aaa-aa) Kevin Cameron (National)
(---a-a) Kurt Takara (0-in)
(--a--a) Michael McNamara (Verisity)
(aaaapa) Mehdi Mohtashemi (Synopsys)
(-aaaaa) Neil Korpusik (Sun)
(aaa---) Paul Graham (Cadence)
(aapaa-) Peter Flake (Co-Design)
(a-----) Roy Armoni (Intel)
(aapa-a) Simon Davidmann (Co-Design)
(-aaaaa) Stefen Boyd (Boyd Technology, Inc.)
(aa---a) Steven Sharp (Cadence)
(-aaaaa) Tom Fitzpatrick (Co-Design)
(-----a) Tim Corcoran (WHDL)
(-----a) Stephen Meier (Synopsys)
(-----a) Arturo Salz (Synopsys)
(-----a) Zeev Kirshenbaum (Verisity)
(-----a) Brad Pierce (Synopsys)
a => Attended
p => Attended by proxy
- => Missed
Mehdi presented the clarification document (including further
ammendments to the clarifications document), and in particular
presenting conflicts that were identified between the testbench
donation and SV, proposing also resolutions. In most cases, the
donation was changed to adopt the SV approach/syntax/semantics.
Specific issues of the committee with the clarification:
* Proposal for $cast_assign()
Questioned by the committee, requires more discussion (e.g. how
does it relate to the static casting in SV? Can't the compiler
do this automatically?).
* Proposal for multi-dimensional arrays
int Array[8][32] as a shorthand notation to int Array[7:0][31:0]
The shorthand notation has already a meaning in Verilog (a single
item, accessed by indexes 8,32).
* Proposal for built-in string methods
The committee pointed out that these are not consistent with the
regular system task syntax in Verilog (the donation was in the spirit
of following a class method syntax).
* Noted that examples in clarification doc still have
brackets around class declaration instead of proposed
class/endclass
* Proposal for use of typedef for forward referencing of classes
The committee pointed out that if this is introduced in SV, it
should be applied in other places as well.
Cliff - typedef usage seems related to other typedef discusssions.
* Mac - Noted that extern is being withdrawn, but that it's related
to other discussions in process.
* The differences between a class and SV's struct
e.g., why can't a class be static too? In particular, in
respect to possible synthesis issues.
* Inheritance
Some comments in the committee about different syntax origins
and consistency (C++? Java?) of constructs, e.g. 'super',
'extends'. In particular, there appears to be no reason to use
'local' rather than 'private'.
* Class, Object Methods:
Mac: page 43: clarification needed on automatic memory
management, out of scope can also cause memory to be
released
* Inheritance needs to be added to the donation:
extends, virtual, protected and super keywords
* Question
TF: How many people in the room are not familiar with OO, C++?
Answer: Most are
* Question - Tim C.
Would classes be in the general language?
Would everything migrated to the general language or would
unique things remain in the testbench std.?
Answer: not sure. TBD
* A new revised veralite proposal will be available and will
contain all the proposed resolutions.
* Virtual classes vs. interfaces
Not clear how these relate to each other, and are they the
same. Needs further discussion.
* local keyword instead of private
Mac: local is also used for parameters; private would be better
Confusion on virtual section 9.7.7. last paragraph
Tim C: question : virtual methods and SV interfaces seem to be overlapping
Kevin: a class is not synthesizable.
* Linked Lists
Why special handling for linked list?
It is fairly common to use linked list for stimuli and verification.
A list is defined as a macro
* fork ... join
Questions regarding how this relates to the SV equivalent
(process?)
* Proposed event to be treated as a superset of SV
trigger will turn the event on
trigger and sync are a superset of -> and @
* Predefined constants (SEMAPHORE, ON, ONE_SHOT, ...)
SB: is a semaphore a keyword?
Arturo: No it is a predefined constant.
Requires further discussion, as this might in fact introduce
new keywords. Appears also in clock domain declarations:
CLOCK, PSAMPLE, PHOLD, NSAMPLE etc.
* Mailboxes
Francoise: Why would mailbox and semaphores not be
implemented as classes?
Arturo: It was implemented before classes came.
Is it a duplicate of SV's queues?
Apparent overlap with discussions regarding channels and
queues in SV.
* Program blocks
Entry point for testbench execution
Multiple program blocks can be defined
Kevin: is this different from $root?
Can the port list be overlapping with interfaces?
Arturo: no it is more like a module. The Vera program is
instantiated with the dut.
Mac: With the program keyword, donation does not blend into SV.
Program block restricts testbench semantics in 1 block, and
makes a program a special construct.
Requires further discussion as to how a program block reconciles
with a Verilog module, and why do we need that as it creates a
difference between the testbench and the design parts.
* static variable initialization
What is the behaviour of initialization of static
variables in Program block ?
page 18 of SV3.0:
section 5.4: sv initialization of static variables must
occur before the initial block.
* Scoping rules
A program is just like a module
clocking_domain replaces the interface keyword (name
collision with SV interfaces)
* vera interface (clocking_domain) issues:
Curly braces "{", "}" in clocking domain declarations
Predefined constants (creates reserved words?):
PSAMPLE, CLOCK, etc...
Ports defined in multiple clock domain:
If out1 is defined in 2 clocking domains, can
you do out1 = 1? what is the effect?
can you do d1.out1 = 1?
Skew definition: Is it too restrictive in light of
Verilog 2001 negative timing checks?
There's no support for a positive skew for sampling
values (sampling with NSAMPLE/PSAMPLE allows only
negative skew: #-<skew>).
* Cycle Abstraction
The simulation will require test bench execution
after all signal propagation just before $monitor
* Wrap-up:
Alec S: Anything in the donation that will help map the testbench onto
a testing equipment to test the actual silicon when it's there?
Arturo: No.
Some of the members expressed amazement from the flexibility of
Synopsys to make all the changes in the sytnax to adapt it to SV,
and that this shows Synopsys is really serious about donating this
and integrating it with SV.
Cliff C - Would users find this useful?
Dennis - Is it a "still-born" language addition that wouldn't
interest anyone (would they only want full vera)?
Mac - Does it provide adequate draw for users for non-Synopsys
companies to implement it?
Dennis - Is this sufficient?
The Sun representative indicated some of the users will
not want to use the VeraLite subset since so many VERA constructs
were taken out of it. Others said this is a good addition to
Verilog, and a clear win to users that write testbenches in Verilog
only, though probably not so useful for users of VERA/Specman.
This donation will therefore help solve the problem (verification?)
for the segment of the market that is not using VERA/Specman.
How are the proposed vera modifications to SV syntax going to
be received by the user community?
This is going to be a big change for the users.
A request came up to have something that can be shown to users and
get their feedback/alpha, in light of the many changes done to the
proposal in the last moment.
A comment: More work needed to clean up the proposed language, to
clarify differences between testbench parts and design parts,
before it's ready to be implemented.
Cliff suggested the committee voted today to accept the donation,
saying "we like the idea", with full power to change and rewrite
any required parts.
Cliff wanted to vote on the donation immediately after the discussion however
Francoise and others wanted to have the opportunity to review the clarification
document before making any decisions.
Cliff moved and Niel seconded that we do an email
vote, to be completed by Sep 16th.
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Mon Sep 09 2002 - 12:50:26 PDT