SV-EC Committee Meeting. Monday January 22 2007 11:00am - 1:00pm PST [Minutes distributed for review, to be approved at next meeting] (121202020102) Day (481593604882) (000011111100) Month (889900112211) (000000000000) Year (666666666677) --------- Attendees ---------- (-AAAAAAAAAAA) Arturo Salz (--AAA-AAAAAA) Cliff Cummings (AAAAAAA-AAAA) Dave Rich (AA-A-AAA-AA-) Francoise Martinolle (-AAAAAAAAAAA) Mehdi Mohtashemi (AAAAAAAAAAAA) Neil Korpusik (AAAAAAAAAA-A) Ray Ryan (AAAAAAAAAAAA) Gordon Vreugdenhil (AAAAAA--AAAA) Steven Sharp (--AAAA-A----) Phil Moorby (---AA-AAA-AA) Doug Warmke (AAAAAAA---AA) Stu Sutherland (-AAAA--AAAA-) Heath Chambers (-AAAAAA-A---) Don Mills (--AA--A---A-) Jonathan Bromley (--A---------) Logie Ramachandran (----AAAA---A) Melvin Cardoza (-----A-AAAAA) Mark Hartoog (-------A----) Satia (from Intel) (--------AAA-) Rob Slater (Freescale) ^ |------- non-voting meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// January 22, 2007 ///////////////////////// Agenda: 1. IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Cliff - Assume that the patent policy was read Second: Mark Abstain: none Opposed: none passed 2. Review meeting minutes/Notes: --------------------------------------------------- Review meeting minutes December and January 8th meetings http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_4_2006_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_18_2006_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_January_8_2007_Minutes.txt Move: Gordon - Approve meeting minutes of December 4th 2006 December 18th 2006 Januaray 8th 2007 Second: Dave Abstain: none Opposed: none passed 3. Action items review ------------------------- AI: 890 and related items: Cliff - update the proposal using new terms (active event regions and reactive event regions) [DONE] includes new diagram and new wording 1/22/07 Cliff - update the figure to make it more clear there are two inner loops. Cliff - Last paragraph page 1 -- change it to pre-active. NOT completely done, next week to make more changes, new wordings. Cliff sent out an update, with a new diagram. Stu provided a lot of feedback on that version. Cliff will make more changes to the proposal and will also send out an email that explains the justification for program blocks. ALSO send out the example for justification, AI: 1325 Stu: check with Karen on how to sort for the required LRM changes that he is currently working on. AI: 1706 Gord: will put something together for review. Action items: Previous meetings ------------------------------- AI: follow-up to mantis 978 Gord - re-write section 5.15.4 - only the default argument value makes sense All - 5.15.4 (last example - can anyone come up with a realistic example? - not only where you would need it but also what does it mean. 1087 - multi-dimensional arrays - is related to this. Dave - what order is used for find and find_index (e.g. traversal is left to right of the bounds, associative is min to max) - 5.15.1 - change last sentence in first paragraph. 1721 - find and find_index (opened Jan 22 - Dave Rich) Neil - most of this is covered by other mantis items... 1690 - array reduction methods for non-integral types (using with) 1576 - unique and unique_index sections need to be reworded 4. Name Resolution sub-group update ------------------------------------ Gord - Lots of discussion on upwards name resolution (hierarchical references). Most of the name resolution issues are being resolved by the svbc. The svec is being copied on some of it so that they are kept informed. 5. Continue review and discussion on Mantis 890 and related mantis items ------------------------------------------------------------------------- a) Rob's use model: Rob wasn't in the meeting and no input was sent out. b) 890 08-31-06 clarifications in program and clocking blocks (Doug) Additional mantis items (there were no discussions on this set) 236 - should be resolved... ##0 597 - [NOTE: look further down in the minutes-- CLOSED] 608 - being clarified. 609 - association of clocking block, need a syntactic form. 1325 - was closed by SVAC - unnamed clocking blocks 1615 - was approved already - allows fork/join_none within functions 564 - Cross-program variable access (Sharp) [recommendation: to close] 551 - Program block interaction with queues (Sharp) Doug: update from the last email Cliff example of assign to clockingblock output? LRM is silent on procedural assign to the same variable as cb output. What about a continuous assign to the same variable? Steven: no other drive if it is continuous assignment, illegal Only one continuous driver should be allowed Dave: A clocking-block (cb) drive is a process or continuous assign variable - process wire - a continuous assign from a pseudo driver Steve - If there is a continuous assign then only allow a procedural assign to the same point. Gord - How is cb drive interacting with other assignments? Arturo: clocking block is considered procedural assignment Steven - If procedural assign - already defined. Doug - Procedural assign and cb drive to same variable is allowed. - What about continuous assign and cb to same variable? Steven - Not allowed Arturo - cb is process - so we should follow existing rules. Cliff - cont assign to net and cont from cb to a wire (net resolution). Gord - cb output implies a procedural assign (may not have a drive though) continuous assign to same would be an error? Jonathan - Emailed during meeting (he seems to agree with the discussion). Doug - Jonathan mentioned 15.14.2 (special drive resolution) Assumes it would be more natural. No one has implemented it yet? Steven - Cadence would prefer to simplify things in this area. Arturo - Good for users - bad for developers. Cliff - 2 cb to same output. Doug - Extra checking was specified in LRM (could add to an implementation). Arturo - Not easy for users to add an assertion for this type of check. Gord - Would be useful to express that type of check Francoise - Conflicting synchronous drive (use pli callback?) VPI access is avail for this. Cliff - Two clocking drives to same output. could be a race Arturo - Typically means a bug in code if drive same cb output at same time. Steven - Would be preferable to warn and not do net resolution. Dave - uwire is one way to try dealing with it. Arturo - Would like to give users access to internal variable if make this change. Gord - Wants to limit amount of access. eg. no write access Could change cb output syntax to specify if unique driver only. Would allow the error catching of original LRM intent. Arturo - Would this be the default? Doug - Thinks users would be used to normal verilog semantics. Steve - Adding "unique" to cb output says you want the checking. Doug - Jonathan made a point about how cb complicates matters for things other than vectors (e.g. his transactor example). Dave - Wants to defer this feature (unique) to later. Prefers to leave us with existing verilog resolution. Doug - Next issue - dynamic types Gord - cb drives to dynamic variables is the issue. handle - handle might change (e.g. become null) - use value of handle when cb drive occurs or when the drive is applied? We need to define it. Harder to specify than a regular nba. If can't do an nba then can't to a cb to it (can at least say this). This would be a reasonable restriction for now. Jonathan said - if ok for nba it should be ok for cb output. Clone the set of things that an nba can't be applied to and also say "a cb drive can't target a dynamic object". See end of 6.6 Steven - All things illegal as nba, should not be allowed in cb drives. Doug - Strengths on wires driven by cb outputs. Francoise - That would be an enhancement. Gord - Agreed Steven - Not sure if that is useful (but would be symmetric). Doug - Could use a temporary wire. Gord - Implicitly part of output (add it as though it is a driver to a wire) We could add strength that way. Steven - Strong is the default Doug - Default net type Steven - Strength not part of drive that way (?) - Could drive a dummy net that has a particular strength. Could Use that as a possible work-around. Gord - Would like to wait for cb drive issues to stabilize a bit before we add a strength enhancement. Gord - Another corner case (addressed yet or not?) A cb output drives a net If no drive for 1st 10 clk cycles what is output driving? (i.e. until it is explicitly driven) "Implicit driver" for this case - means continuous assign he thought If a continuous assign it means X until it is driven. For a variable - cb doesn't do anything to the variable until driven. If cb output drives a z - does it come up as z or x if not driven? - Prefers to be same as rest of SystemVerilog and come up with x in reg Steen - Never really gave much weight to the idea that nets start out at one value and then settle at another. Cliff - A net would be z until driven? - bidi - if driven from outside as well - Undriven bidis usually appear as z - At time 0 there would be an x (skew prevents drive right at 0) Steven - If comes up at z a driver "will come into existence" when first drive - Assigning a z to it - could think of this as turning off a driver. Gord - The most natural would be to provide x - For 2-state just get default. - Using the normal verilog default value is the best approach. Steven - z not valid for 2-state Doug - Example: Given a set of interfaces and cb's where not all are used. Some cb outputs never receive continuous drives. Gord - If not being used in a particular design - use generate and compile out of design. Neil - The use-model that Doug is describing happens all the time. There can be several cb built into the testbench but not all of them are used by every test being run against that model. Each test may only use a subset of the cb. It wouldn't be practical to require unused cb to be compiled out. This would potentially require a separate build step for every test. Doug - What about - if no drive then the cb output has no affect. Gord - Topology versus behavior - A cb in the elaborated design - is a driving relationship (has been his assumption) - Can accept initialization to z (what about 2-state?) - Not comfortable with treating it as though no driver exists. Steven - Can't think about a driver coming into existence Cliff - Requires an enable. Doug - Doesn't want drives to resolve differently Gord - If only one cb drives - get the driven value other 9 would default to z - If ask about the number of drivers - get all 10 Steven - If define cb drive as being different from other verilog constructs would need to define everything about it (vpi, etc.). - Only 4-state is a special case (2-state no z) Francoise - Not sure if vpi will show cb output as a driver, continuous assign or port or primitive terminal. Gord - Internal variable as the driver (being driven by cb) Stu - In vpi - want the cb output showing up as a driver (not an implicit continuous assign) Gord - Need to specify the actual output itself, not the whole cb. Francoise - svcc wants to see the whole proposal for mantis 890 - to understand the impact to their work. - wants to see the whole thing written up. AI: Francoise: Bring this discussion to sv-cc (Clocking-block driver on a net) 5a) discussion about next p1800 meeting (Tuesday Feb 20, 2007) -------------------------------------------------------------- 890 - Doug un-volunteered himself but willing to review Cliff - might be willing - based on state of 890 15-20 minutes (15 pres and 5 discussion) Stu - Suggested simulation semantics event region descriptions reordering based on the event order. Cliff, Neil and Mehdi - all agreed with this. Neil, Mehdi - easier to see inner loops if outer loop is on other side. AI/Cliff, Neil, Mehdi - P1800 presentation on 890 AI/Cliff - update the event scheduling writeup. 6. Additional mantis items ------------------------------------- 1336 12-04-06 Rules for allowed statements in a function(Dave) Dave: follow up to 1615, additional clarification what is allowed inside the functions once we allow fork-join/none in a function then non-blocking assignments inside a function would be ok. Dave made wording changes based on email on the reflector. Steven - Task enable on last bullet, is redundant Gord - A constant function shall not have a fork/join_none - constant function doesn't need to restate a restriction already in effect for a function. Dave - An empty fork/join is allowed today Steven - Would like to exclude fork/join for all functions Gord - No inherent problem allowing nba in other contexts useful for initialization (within a function) Steven - Why this "originating thing"? Once in a fork join none can do a lot Gord - Not an issue with fork join none outside of fork join none (bare function code) No technical reason to disallow for cont assign (but it is weird) declaration assignment - no inherent reason to restrict it but a family of restrictions to make things simpler Mark - Functions called from assertions Dave - Not allowed. concurrent or immediate assertion? immediate not an issue Mark - Not a thread Even though in always block, it doesn't really run there Arturo - "allows statements" use plural here. 12.3.4 2nd sent Mark - Action blocks - can these functions be called from there concurrent assertion - not part of thread of an always(action) block Runs in reactive region. Steven - Not comfortable with this working of "originating... "If the parent is an initial, alway or from a fork/join thread." Phrasing it in terms of thread calling the function would be better. Dave - It doesn't handle assertions with that wording. Mark - What about declaration assignments (for automatics). Steven - That is ok - same as an inline assign in the block Mark - Not allowed for static variable initialization. Steven - "any context other than procedural code that is an initial, always or a fork/join thread". Allow anything once you get into a fork/join. - other section (eg 1615) Steven - Deal with 1615 and 1336 together to be consistent. Move: Dave - Approve proposal for mantis 1336, with friendly amendment. Modify last sentence of 12.3.3, only say fork join none. [attachment 1336_final.pdf] Second: Gord Abstain: none Opposed: none passed 1371 03-09-06 Semantic of program block $exit (DaveR) -- Clarification Steven - Suggested that $exit only be callable from a program block. Dave - What about packages? Gord - System task calls are ignored from constant functions. Arturo - The proposal changes the original semantics. top-level process terminate - kills off everything else. Gord - initial with fork join none spawns activity Steven - Can use wait_fork Arturo - Wait fork recursively. - Prefers to leave semantic the same as it was before. Steven - continuous assign or force - alway alive? Arturo - continuous assertions Dave - Just on parent process when all initial blocks finish(?) Steven - Use wait_fork if want to wait for children. Gord - Assumes at least one initial block... Arturo - An empty program should exit. What is the purpose of it? Dave - It could contain assertions. Steven - If all program blocks are empty and the simulation doesn't end. That would not backward compatible. - For $exit need to keep track of where came from (call chain) Dave - For explicit calls need to take more into account. 7. Discuss what to do with mantis items that have no proposal ----------------------------------------------------------------- 8. Next meetings -------------------------------------- Feb 5 Monday, 11:00-1:00pm (Gord, Stu not available) Feb 19 Holiday -- No meeting Feb 20 Face-to-face meeting, at the Mentor site in San Jose There is a p1800 meeting from 11-1:00 sv-ec can have 1:30 to 3:30pm DVCon is during that week Mar 5 Monday, 11:00-1:00pm ========== ADDITION TO the minutes, not part of regular ========= ========== meeting discussions, informational purposes ========= ========== Action Items updated based on January 22 2007 ==== Action items: January 22 2007 ------------------------- AI: 890 - Francoise: Bring this discussion to sv-cc (Clocking-block driver on a net) AI: 890 - Cliff, Neil, Mehdi - P1800 presentation on 890 AI: 890 - Cliff - update the event scheduling writeup.