SV-EC Ballot Resolution Committee Meeting Friday April 29th 2005, 1:00pm - 3:00pm PST [Minutes distributed for approval at next (sv-ec) committee meeting] (011112222) Day (412581589) (000000000) Month (444444444) (000000000) Year (555555000) --------- Attendees ---------- (-AAAAAAAA) Arturo Salz (AAAAAAAA-) Brad Pierce (AA--AAAAA) Cliff Cummings (AAAAAAAAA) Dave Rich (AAAAAAAAA) Francoise Martinolle (A-----AAA) Karen Pieper (AAAAAAAA-) Mehdi Mohtashemi (AAAAAAAAA) Neil Korpusik (AAAAAAAAA) Ray Ryan (AAAAAAA-A) Steven Sharp (AA-AAA---) Surrendra Dudani (-AAAAAAAA) Gordon Vreugdenhil (-----A-A-) Dennis Brophy (-------AA) Phil Moorby (------A--) Tom Fitzpatrick ^ ^ ^---- Non-Voting meeting (4/29/2005) ** Minutes taken by Neil Korpusik Agenda: 1. IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Assume it was read - Cliff Second: Gordon Abstain: Opposed: 2. Non-voting meeting Mehdi was unable to attend this meeting. Since it was called at the last minute of our meeting on the previous day we decided to make it a non-voting meeting. Neil was acting as chair. 3. Open issues *** issue 30 (Mantis) 549 - chapter 15 - scheduling semantics - <<<< continuation of last meeting 4/28/05 >>>> At the last meeting we left off discussing section 3.1 text of the mantis 549 problem description. That is where the discussion picked up in this meeting. Gord - problems arise when programs call module tasks/functions which contain assignments - first order effects seen by 2nd program - problem - 2 threads - program thread can wake up 2nd thread not even semi-stable about when updates occur Arturo - program calls a task in a module you see its effects immediately Gord - not worried about the 1st order affects - worried about always, cont assigns that are sensitive to updates - there can be data-dependent controls - it would probably be easier to reason about program vs module if we knew that the only thing that could be in-between processing in the reactive region for the same time slot are the first order affects caused by assignments due to program block activity. - would be good if when reactive become active - program activity runs off reactive Q and keep running program stuff until there is no more program stuff. Arturo - if truly synchronous design - some comb logic will propagate and stop at latch inputs. - doesn't know how to make the current loophole smaller without hamstringing the language. dave - if assume modules are using always @(posedge clk), what is the harm of modifying design, why is there an issue about what Q things run in? Why are we being so careful about what the program block changes? gord - program block could cause a design state change via a task that could cause always or cont assigns to become active. This will happen in-between 2 program threads. If a second program thread is woken up. Partial waves of activity can go through the design each time we pass through the NBA region on our way back to the reactive region to process events in a program thread that has awoken. dave - within the program block we can only use BA (no NBA allowed) 2 program threads waiting for edge of clock and want to communicate with a variable. There is a race here. Arturo - there are synchronization mechanisms for dealing with this. In c there is no NBA concept. - program block not designed to be synchronous. wouldn't be opposed to another region that would use program NBA Not sure we need it. Today trying to allow changes in a controlled manner. gord - There is an opportunity to get closer to original goal by closing off the 2nd order effects. - Was there consideration made to allowing iteration of the reactive Q by itself? This would give program threads a higher degree of stability than we have now. Arturo- trying to describe this in the LRM would be a mess. Arturo - would like to make changes in module to be in a separate delta-cycle of a program. What about calls to a static task? - we know of this loophole but not sure if this is a bad thing. gord - can't plug direct assignments - program calls a module task that updates a module variable - the 1st order effect. dave - program calls to module tasks are most often for initializations - some updates can't be by NBA - dynamic arrays, etc. - no one that writes synthesizable code adds initial blocks. Arturo - We are using the program construct to create a barrier from active and reactive region. dave - We lose ability to do some things without a program block. can't use a clocking block properly without a program. Arturo - other examples of calling verilog tasks from the program include the following: CRC calc - function call - not injecting values. - blocking task calls from the program are truly rare. - The existing hole allows message passing between reactive and active regions. Connecting modules via message passing. gord - t1 reads module state and t2 reads state if program did deltas that wake up t2. Arturo - sample first program on entry. - other examples are truly asynchronous. - gord wants to force an extra delta cycle in reactive region. gord - if others aren't worried about the 2nd order effect then we should move on. Francoise - thinks it would be best to exhaust the reactive region. arturo - jay was opposed to this. phil - initial model was similar to what gord is proposing. phase 1 - design phase 2 - assertions phase 3 - testbench They even considered no feedback at one point in time. Jay was against it. He wanted everything to run in active region. gord - a call to a pure module function will block to active region - we should loopback to active region after looping within reactive region - trying to prevent behavior that can sneak in-between program thread execution Arturo - downside of the double-loop program calls a module task - blocks - program goes to sleep fork 3 threads - parent thread runs last - how do this? gord - #0 in reactive region? Phil - that would be different than #0 in module. Arturo - NBA reactive region - didn't see any opposition to this concept francoise - why need a new region? gord - 2 program threads doing module NBA, want at same time? - p1 trig event to p2 nba to design variables 1. nba to design first 2. p2 wake up first - want this one first Ray - 2 threads: if do NBA to module before fork threads then second thread sees NBA effects Gord - second looping of reactive region would resolve a lot of this. - with second loop don't need reactive NBA. Ray - Sees two options: 1. reactive nba - seems to also require additional pli regions cont assign to non-program variables program nba to module variables done here 2. looping of reactive Phil - Could possibly add later if needed. phil - is concerned about side effects. - His test of what is good: lift code from a module and plunk it down into a program. It will now run in reactive region. May contain PLI calls. concerned that things will now go wrong. module code may be testbench code. Doesn't like fact that no NBA on program variables. Thinks that reactive-nba is only way for it to work. - Originally looping was like phases - concern was about couldn't get back to active region from phase 3. Second issue was Jay. Phase 1 and 3 were mirror images of each other. gord - dangerous to try to make pli calls that make assumptions about active region. ray - need to change BA to NBA? No - module variables would have become program variables in Phil's example. Arturo - if would want to allow NBA in testbench you could do it with a reactive-NBA region. Ray - program cont assign to mod variable - like a jumper? Dave - program does both sync and async things. - if a continuous assignment is combinational logic it shouldn't matter which region it is scheduled in. gord - same issue with 2nd order effects. - all 2nd order effects will continue to occur in-between threads. - continuous assignment living in program would behave different from module approach - can use hierarchical reference to anything in module today? Arturo - Thinks it is not allowed. Gord - not in lrm. Should use ports for this. Should have written this in the LRM. Arturo - would prefer a syntax cont nba in a program to allow program to drive via cont assing - would be in reactive region. - program to program ok but weird. - need a way to drive back to module via program ports. Neil - also need inactive-reactive? Arturo - #0 in program would be different from module - do see people suspending threads and waiting for them then coming back alive. cliff - bad idea to use #0 Phil - doesn't like #0 - people do use it though, it is here to stay - if add reactive nba - do need inactive as well - may need both - the loop back on reactive and reactive nba Arturo - orig vera donation - had suspend thread - jay said same as #0 - could also claim that people don't need cont assigns as well. Dave - there is still a way to get back to active region vs original donation. gord - how much language in lrm about active Q Dave - misnomers in assertion section about reactive region. Phil - there are some other misnomers in lrm as well. Arturo - mixed language simulators - vhdl, verilog - completely combined semantic issues. gord - cross-domain scheduling is an interesting exercise. - reactive subloop wouldn't add much complexity and should make it easier to reason about execution. - doesn't see any issues with reactive region loop cliff - sounds like no effect by adding this to bilingual simulators. Dave - shouldn't affect svac - how capture what we just said? Gord - need to change reference algorithm for both options. Arturo - either one ok. Phil - thinks both are required together. - need to explain #0 in a program. - thinks that we need an inactive-reactive region - all regions active to observed replicated - including pli regions Arturo - need to say things like program to program nba in the language. - problem if #0 behaves differently in program vs module - where would a vhdl postpone process go? Steven - what about performance? Cliff - can we just do some minor tweaks here and then come back later? - concerned about doing major surgery at this point Arturo - the danger is real - otherwise we could end up with incompatibilities Gord - there is some nice condensation in the algorithm today - "scanning iterative regions in order". will now be more difficult to describe it. - 1. people understand intent and 2. is writeup clear Arturo - it was always understood that vendors could add extra regions on their own as long as the original intent was maintained. AI: Francoise; talk to people in cadence about this proposal/issue AI: Arturo; need to get consensus within Synopsys first AI: Gord; send out a description of the sub-loop option and the other option that was discussed today - Gord will just send out info on the reference algorithm and not the diagram. - combination of both options as well. *** issue 30 section 4.1 #0 - gate delay is actually 0. Mantis - 713 - #0 in procedural code does mean inactive region. AI: Arturo; write up proposal. page 188. Section 15.3 - The following wording was also proposed: From: An explicit #0 delay requires... To : An explicit #0 delay control requires... *** issue 30 section 4.2 cbReadWriteSynch - cc committee made some changes for this already - duplicate of mantis 372 - changes both 1364 and P1800 Francoise - Charles and Francoise disagree on this one. - can't be deprecated - in use. Arturo - writable before postponed region - thinks we should leave the ambiguity in there. Recommendation: SVEC won't address since duplicate of 372. (Note: this was a non-voting meeting). *** issue 30 sections 5.1 and 5.2 - just style issues - no changes needed *** issue 31 (Mantis 551) - issues related to the program block - most of the issues here are duplicates of 549 - the last issue raised by this mantis item - dpi related. This issue does not overlap with 549. Francoise - is DPI called in module or program? Dave - event controls not in the dpi itself Arturo - dpi can call a blocking task. dave - it could be in any regions Arturo - task in module calls exported task from program possibly detect at runtime? cliff - when call dpi from design? high-level modeling. - back to c domain steve - block of task is statically determined based on where declared. Arturo - additional stuff to keep track of is required. cliff - likes idea of being restrictive for now AI: Arturo - will write up a restriction on this. AI: Neil - send to cc AI: Dave - contact Doug for his input on this. Francoise - what about the point about assertions? Dave - concurrent assertion. - only apply to procedural code. - they execute exactly the same (in active region) AI: Neil - An assertion in a program versus in a module execute identically. Program semantics only apply to procedural code. *** issue 32 (Mantis 553) - more scheduling related issues 3) Next meeting Our next regular meeting is scheduled for Wednesday May 4th 2005 from 11:00 am - 1:00pm PST. ================================================================================= Action items: (4/29/2005): 1) AI(issue 30, Mantis 549): section 3.1 of text in mantis AI: Francoise: talk to people in cadence about this proposal/issue AI: Arturo: need to get consensus within Synopsys first AI: Gord: send out a description of the sub-loop option and the other option that was discussed today - Gord will just send out info on the reference algorithm and not the diagram. - combination of both options as well. 2) AI(issue 30, Mantis 549): section 4.1 Arturo: write up proposal. page 188. Section 15.3 - The following wording was also proposed: From: An explicit #0 delay requires... To : An explicit #0 delay control requires... 3) AI (issue 31, Mantis 551): Arturo: will write up a restriction on this. Neil : send to cc Dave : contact Doug for his input on this. ==================================================================================