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.