________________________________ From: Lisa Piper Sent: Thursday, November 15, 2007 2:41 PM To: 'Kulshrestha, Manisha'; sv-ac@eda.org Subject: RE: [sv-ac] 1648 - default disable iff Thanks for reviewing this so promptly! I have some comments and questions below. ________________________________ From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] Sent: Thursday, November 15, 2007 12:36 AM To: Lisa Piper; john.havlicek@freescale.com; sv-ac@eda.org Subject: RE: [sv-ac] 1648 - default disable iff Hi, With the change in the name of default disable, I would like the title of 16.15 to reflect that change i.e. change the title to 'Default disable iff resolution'. [Lisa Piper >>>] done I do not think that section 22.8 has any information about how default disable iff should be resolved. It only deals with variable, task, function, named block and generate blocks. So, how do we treat default disable iff : like a variable declaration or a task declaration ? I think it is better to have scoping information in this section itself as default disable iff does not behave like any of the above. There is another statement "It provides a default disable condition to all concurrent assertions in the scope of the default disable iff declaration, in accordance with the scope rules of 22.8.". I am not sure which scoping rules are we referring to from 22.8 ? [Lisa Piper >>>] I was mostly referring to: "If an identifier is referenced directly (without a hierarchical path) within a task, function, named block, or generate block, it shall be declared either within the task, function, named block, or generate block locally or within a module, interface, program, task, function, named block, or generate block that is higher in the same branch of the name tree that contains the task, function, named block, or generate block. If it is declared locally, then the local item shall be used; if not, the search shall continue upward until an item by that name is found or until a module, interface, or program boundary is encountered. If the item is a variable, it shall stop at a module boundary; if the item is a task, function, named block, or generate block, it continues to search higher level modules until found. This fact means that tasks and functions can use and modify the variables within the containing module by name, without going through their formal arguments." I was picturing that you can declare a new "Default disable iff" in any scope were a re-declaration is allowed, like a variable, and then this applies. I guess with the BNF as it is, this is not true - it cannot be defined in a named block or task or function. In the proposal it says: "Declaring more than one default disable iff item within the same module, interface, or program shall be an error." . This statement does not fit with the new scheme of allowing default disable iff in generate blocks. Because effectively there may be multiple declarations inside same module but they may be in generate block in the module. [Lisa Piper >>>]. I can still re-use most of the wording from 22.8: Default disable iff shall be declared either within a the task, function, named block, or generate block locally or within a module, interface, program, task, function, named block, or generate block that is higher in the same branch of the name tree that contains it. the task, function, named block, or generate block. If it is declared locally, then the local item shall be used; if not, the search shall continue upward until an item by that name is found or until a module, interface, or program boundary is encountered. (so nested modules would not be able to adopt the default disable of the top module - is this ok? Should a default disable iff also apply to instances contained in the module - I thought not since signals must be ports. ) More than one default disable iff item within the same scope is an error. I thought of another interesting question. If I define my default disable iff at my top level module to be a signal called reset, and then I have a generate block within that defines its own reset signal but does not re-define the default disable iff, then which reset signal is used? I would assume it is the reset in the scope of the default disable iff definition. Do you agree? I think referring to module, interface and program everywhere in this paragraph is not right as default disable iff can be inside generates also. Thanks. Manisha From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper Sent: Thursday, November 15, 2007 2:51 AM To: john.havlicek@freescale.com; sv-ac@server.eda.org Subject: [sv-ac] 1648 - default disable iff The change was pretty simple as it turns out. A default disable iff may be declared as an item within a module, interface, or program. It provides a default disable condition to all concurrent assertions in the scope of the default disable iff declaration, in accordance with the scope rules of 22.8. I made one other change. The label and section number for 16.48 was wrong. It was a duplicate of the previous. I did not make any other changes. I have uploaded it to Mantis. Lisa -----Original Message----- From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John Havlicek Sent: Tuesday, November 13, 2007 9:22 PM To: sv-ac@eda.org Subject: [sv-ac] notes from SV-AC meeting 2007-11-13 Hi Folks: My notes from today's meeting are attached. Please let me know if changes are required. J.H. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 20 09:42:02 2007
This archive was generated by hypermail 2.1.8 : Tue Nov 20 2007 - 09:42:28 PST