Brad, I think the answer to your question is "It is implementation specific" P1800-2009 Sec 3.12 says: Although this standard defines the results of compilation and elaboration, the compilation and elaboration steps are not required to be distinct phases in an implementation. Throughout this standard the terms compilation, compile and compiler normally refer to the combined compilation and elaboration process. So, for example, when the standard refers to a "compile time error", an implementation is permitted to report the error at any time prior to the start of simulation. So I don't know that you'll find an airtight argument from the LRM, since it looks like the LRM is going out of its way to avoid giving airtight definitions of what exactly happens at compile time and what exactly happens at elab time. That being said, I believe I agree with you that a 'false' conditional generate should still get a name. ~Alex -----Original Message----- From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce Sent: Tuesday, May 19, 2009 11:44 AM To: sv-bc@eda.org Subject: [sv-bc] genblk counting -- known during analysis, or does it depend on elaboration? 12.4.3 of IEEE Std 1364-2005, discusses "External names for unnamed generate blocks", or informally "genblk names". I believe the counts used in these genblk names are fully known by the end of analysis. But it's been argued to me that because hierarchical generate block names cannot be determined until elaboration time, then neither can the genblk count. For example, it could be argued that the following nested generate blocks (conditioned on 0) don't exist, have no implicit name, and don't get counted when naming genblks. for (i = P; i < Q; i = i + 1) if (0) assign out[P] = 0; I don't agree, but can't find an airtight argument from the LRM. The phrase "... construct that appears textually ..." is suggestive, but isn't proof. Is the genblk count known by the end of analysis, or not until elaboration? -- Brad -- 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, and is believed to be clean.Received on Tue May 19 13:00:10 2009
This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 13:01:11 PDT