Minutes from the Errata Task Force Conference Call June 16, 2003
Attendees:
000000000111110000 \
654433211221109998 / Month
112021121101022002 \
691740073628413996 / Day
aa-aaaaaaaaaaaa*aa Steven Sharp
aaaaaaaaaaaaa-a*aa Karen Pieper
---a--aa-aa--a-$aa Cliff Cummings
aaaaaaaaaaaaaaa=-a Shalom Bresticker
aaaaaaaaaaaaaaa*aa Stefen Boyd
a--aaaaaaaaaaaa*aa Dennis Marsa
a-aaaaa-aaa-aaa$aa James Markevitch
a-aa-a-aaaaaaa-=-a Gordon Vreugdenhil
a--aaa-aa-aaaaa$aa Anders Nordstrom
-----------aaa-$a- Ted Elkind
aaaaaaaaaaaaa-a*a- Brad Pierce
aa-aaaaa-aaaaaa*a- Charles Dawson
aa-a---aa-a-aa-$a- Mike McNamara
a-aaaaaaaaaa---*aa Stu Sutherland
a--------------*a- Tom Fitzpatrick
---------------*aa Elliot Mednick
------aa---------- Don Mills
a-----a----------- Jay Lawrence
-----a------------ Mehdi Mohtashemi
aa--aa------------ Kurt Baty
a----------------- David Smith
a----------------- Dennis Brophy
Issue 265, 275, 309, 322, 346 is passed via email vote closing 5/16.
Minutes from the 5/19/03 meeting. Steven moves that we accept the
minutes. Gord seconds. No opposed. James, Anders, Dennis abstain. Passes.
Action Items:
Kurt will edit 140 to reflect his proposal. x ** -y is equal to 1/(x ** y)
with integers. Are there objections to this proposal? Steven
prefers this.
Discussion on what to do with open issues. Karen will equally divide
the open issues and randomly assign them to members of the committee.
Each member will select one or more of their randomly assigned issues to
drive (not necassarily make) to a proposal.
Steven: 3, 6, 9, 16, 17, 22, 33, 35, 37
Cliff has submitted a proposal for 9
Shalom: 16
Gord: 17(generate)
Steven: 22(@*)
35 was closed, and incorporated into 282.
Karen: 47, 48, 54, 57, 72, 73, 80, 81, 82
Karen made a proposal for 47
Steven: 82(@*)
Shalom: 83, 84, 88, 90, 96, 98, 99, 100, 105
Shalom will take 88, 90, 98, 99, 100, 105, 13
83 was closed, and incorporated into 282.
Steven: 84(@*)
96 was closed, and incorporated into 282.
Stefen: 106, 107, 108, 110, 111, 113, 117, 119, 135
Stefen has not been in the office in the last 2 weeks
Did Cliff take 106 together with 9?
Gord: 113(generate)
Steven: 117
119 was passed by etf.
Dennis: 139, 165, 170, 172, 190, 192, 197, 198, 203
Dennis: 139, 190, 192
Steven: 172
Shalom: 198
James: 204, 205, 206, 208, 209, 210, 211, 212, 215
James: 204, 205, 210, 211
Shalom: 206, 209
Gord: 208(generate)
Configs: 212
215 is mixed with 282
Anders: 217, 225, 226, 227, 233, 234, 235, 245, 247
Anders proposed for 235
He'll start with 217 and work his way forward
Shalom: 245
Brad: 248, 250, 254, 255, 256, 257, 258, 261, 265
Brad: 250 (propose we close it), 255,
257, 258, 261
254 should include 319
Charles:270, 273, 274, 275, 276, 277, 278, 282, 283
Charles: 270, 275, 277
Reals: 273, 274
BNF: 276
Stu: 285, 288, 290, 291, 292, 295, 296, 302, 308
Stu hasn't had a chance to look
PTF: 296
(4/21/03) 9: Gord to determine a location of the proposal in
conference with Cliff.
(1/13/03) 13: Shalom to update proposal to 13 reflecting Shalom's
requests.
(11/18/02) Steven and committee to return with an @* proposal for
issues 22, 82, 84
To be resolved after power and generate.
(11/18/02) Gord and committee to return with a generate proposal
for 113, 17.
**We have a draft of the technology for addressing the
issues with generate. Gord will send it out for the
committee to review. Discussing it will be the initial
focus of the next meeting.
The generate proposal is still under discussion. The
primary difficulty seems to be with a need for scopes
for any branch/loop that declares variables. Kurt
would like to see that providing the scope names be
optional. He is willing to require them if you wish to
reference the named objects outside of the implicit
scope a variable is declared in.
Genvar declarations are proposed to change. It is
suggested that the genvar declarations change to be in
the generate for loop. We are looking also at allowing
them to exist after elaboration.
We could also remove generate-end generate.
Pause in action items to talk about DAC. Discussion led by Mac.
Sparcely attended BoF meeting with lots of interest in adding SV
DASC meeting Friday -- interest in a numerics package possibly across stds
SV - Accellera co-operation: No ruling by board about donating to IEEE.
Vassilios sent a 9 month schedule for next version of the SV
standard. That could be a problem for our schedule
We are gathering requirements. We will also host BoF at Snug, Cug.
Question for VSG what do we do? Wait for SV, apply donations
enhancement requests? Mac will call VSG meeting soon to put together
a schedule. In the near term, it seems like we won't see SV until
spring next year.
Proposal for Stephen to do web work, we would pay him.
One proposal from BoF meeting is the need to entirely rewrite the standard.
We would need to pay for editing to help this.
Other sources of gathering info: Snug, Cug, Web pages.
Stu is now chair of the Designer's forum within Accellera. Perhaps this
would be a good audience for a questionnaire. Also comp.lang.verilog?
Mentor, Synopsys, Cadence mailling lists?
One idea was to do a 2005 followed by a 2007, if SV isn't ready to come
over now.
Anders: It is obvious that Accellera won't donate to us because they
dont want us to modify the standard.
Shalom: Users want one stable standard.
Stu: 3.1a will be stabilizing it. Adding PLI, and so on. We know the
features so we can add them. We have some features outside of that
subset we can focus on for the next 9 months.
Anders: We can pick want we like of SV and implement what we like and
ignore Accellera
Jay: We are going to have to consider SV in any decision made.
Anders: Accellera has won then.
Jay: No, we own Verilog and we can decide the features we like and
not follow SV.
Shalom: How about we just fix errata, and let Accellera define the
language going forward. (Hieretical question)
Jay: Cadence believes in the IEEE method. We donated Verilog to the IEEE.
Shalom: Users want one language.
Jay: Users should put pressure on Accellera to speed up donation
Stu: Accellera will be donated, we just don't know when
Jay: The intent of the delay is to make a defacto standard, so we should
disband. We would just be able to rubber stamp the SV language.
Stu: There is a strong history that IEEE does not rubber stamp languages.
Anders: If IEEE modifies it, then there isn't one language.
Mac: The goal is to get back to one language. A good legal solution has
everyone unhappy. Every vendor needs to see a piece of this language
as their own. Users are very afraid to use anything not in 2001
because there is some uncertainty. One language must be a goal.
IEEE is not going to abdicate this language. It generates 10% of
their revenue.
Anders: How come IEEE allows Accellera to call it SV?
Mac: You can site IEEE works. There is great stuff in SV. There are
scorched earth places we can go, but we should try to find a way to
get to one language.
Steven: We can continue to work, and if they don't want to donate, they
risk being marginalized.
Mac: 9 months is what we have to wait for the next standard.
Jay: We have no guarantee for them to donate. 80% of the language is
fine, but we want a resolution to the 20% that has issues. Let's
discuss the donations already here. We don't need to wait for
donation from Accellera.
Kurt: IEEE will take too long to make a standard. Accellera will have
product development sooner.
Jay: ??? (Karen lost this piece of the discussion)
Shalom: What are the legal status for SV, and can we just take it?
Mac: There is a new board with lots of users, so there may be new
direction from the board. This committee needs to get back to
ETF items. We'll try for an 8am meeting tomorrow morning.
ETF agenda resumes.
(11/4/02) Steven will proposing a wording to fix 172. It will be a
significant rewrite.
(2/10/03) Issue 237: SV-BC19-41, SV-BC19-42
Ted Elkind, Dave Roberts to look at it. Charles has asked
them. Charles will check.
(11/18/02) Evaluating TBD Errata. The tasks are:
Steven
117 19.1,19.6,19.9: `unconnected_drive and `celldefine
Steven to propose wording documenting XL's implementation
for both pairings.
Gord
165 13.11.1, A.2.1.1 -- reuse task_port_type
170 formatting of bnf non-terminals - Shalom sent something
one stage before a proposal
Charles
197 sscanf/"string" incompatibility
Shalom
198 sinks should allow only constant part-selects
Shalom will make the smaller change to allow port
expressions to be what is allowed on the lhs of a
continuous assignment.
Issue discussion:
SV-BC Issues requiring resolution: (ETF issue number: SV-BC issue
number)
-237: 19-41, 19-42
Ted Elkind, Abe Roberts to look at it. Charles has asked
them.
326: Escaped names not clearly defined. Issue sent to sv-ec and
forwarded to us. This is a PLI issue number 307. We will
keep this item; however, we are waiting for PTF resolution of
307 before we address this issue.
(- lack proposals)
Generate discussion:
There has been a lot of discussion in the sub-group about the degree of
compatibility and naming. We need to make some decisions about exactly
what we are going to allow ourselves to change. The biggest issue is are
we willing to require blocks to be named within generate. There are some
implementation issues that that will simplify. If we do that, it will be
incompatible with the 2001 subset of generate because it will be a subset.
The changes required could be made to be relatively straightforward. Any
references to those declarations would have to be changed. Those references
are potentially hierarchically.
Most implementations have probably got difficulties with this, having
edge cases where they get it wrong. The issue is only with things that
aren't in named blocks. How about we require labels if you have anything
other than an instantiation? We could also make it work if all references
to a wire are within the generate region? That may be hard to explain to
a user.
Kurt: I doubt that there are many places where there are two things in
branches named the same thing. Cut and paste would be the only reason.
It would be ok for me to say that errors occur if there is a collision in
flat space.
Gord: Small changes (i.e. late decision to have choice pullup, pulldown)
can create a big problem. I'd prefer that all case/if statements have a
named block (potentially the same for all branches). We can't wait to
make this change.
Kurt: I'm using ambit synthesis.
Steven: They don't allow same name in multiple branches.
Stu: How about automatically created names?
Gord: external references to x wouldn't work.
Strawpoll: Are we permitted to make existing designs not work?
Kurt says ok, Stefen says ok, Karen says that Cliff indicated that
he is leaning that way as well. Shalom wants to point out that we are
doing this for the power operator. Stu, width extension beyond 32 bits
for x. Stu: the decision made quickly. Cadence is about to roll out
for generate not if because of difficulties. Same for Verisity. VCS
has if generate, but is not compliant with sub-committee. Ambit does
flattening. MTI is big unknown. From a non-ricoh organization we
shouldn't be creating our schedules from company products.
Shalom: At least where possible, changes should be done such that
they can be forward compatible.
No objections to the poll.
Gord: Simplest proposal. Allow current form for generate, but
outside must use a hierarchical name.
Steven: What about VCD names, etc?
Shalom: Some things don't appear in VCDs, automatic, memories, etc.
Gord: Since names can't conflict, I'm not sure you would need implicit
names for those alternatives.
Gord: Summary of where the subgroup will go: The existing form of
having unnamed blocks will be permitted, but external references
(both within the module and without) to it will require
a label for the if/case branches. All hierarchical names must
remain unique.
This way, only hierarchical names need fancy resolution.
Strawpoll: This is an ok solution.
Gord: Ok, we will start writing that up.
MAC:everyone should join the DASC
Ok, another thing: remove generate endgenerate? Strawpoll, leave them in.
Genvar vs. local variable? Permit genvars, or require them? If permitted
they should take a piece of hte namespace.
Gord: Direction: genvars are optional, when present they create an
entry in a namespace. Also, allow genvar declaration in the
loop body itself.
Strawpoll on above direction: Kurt, Stefen are ok. Anders is ok.
Gord is ok. Steven, Dennis are worried it will be more complicated.
Power operator:
Steven has an issue with the big table. He would prefer an English
sentence to cover the issue. Kurt will convert the table into a
sentence or two. Stefen and Kurt will work together on the proposal.
Shalom: We often have people who have different interpretations of
English statements.
Kurt will send out an email proposal reflecting comments made during
the minutes.
Because many people will be on vacation the 6/30/03 meeting is cancelled.
Next Meeting is 7/14/03 at 8:30am Pacific.