1850 already handles the 'variation' part of it. Shalom ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Thursday, June 07, 2007 6:48 PM To: Lisa Piper; Bresticker, Shalom Cc: sv-ac@eda.org; sv-bc@eda.org Subject: RE: [sv-ac] 22.10 bind review Sorry - 1855 is the number ________________________________ From: Lisa Piper Sent: Thursday, June 07, 2007 11:45 AM To: Lisa Piper; Bresticker, Shalom Cc: sv-ac@eda.org; sv-bc@eda.org Subject: RE: [sv-ac] 22.10 bind review I opened 1822 to track the remaining issues. Lisa ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Lisa Piper Sent: Monday, June 04, 2007 1:12 PM To: Bresticker, Shalom Cc: sv-ac@eda.org; sv-bc@eda.org Subject: RE: [sv-ac] 22.10 bind review Hi Shalom, I disagree that there is any issue with the sentence: "It shall be an error to use noninstance-based binding if the design contains more than one variation of the target module, program, or interface. This can occur in the presence of configuration library mapping or nonstandard functionality such as provided by the `uselib directive." What the LRM talks about is multiple variations of a module( i.e. potentially different implementations of module "child" are compiled in different libraries). And using verilog configurations, the elaborator can bind instance c1 to one variantion of child and can bind instance c2 to different variation, as controlled by the "uselib". In such cases, LRM prescribes the instance based binding. Refer the LRM section 3.8 that talks about configurations and the use of libraries. It uses the the word "variation" and then clarifies that it is referencing configuration library mapping. I think this is important so that implementations of bind do not have to track library information as well. I think (not sure) that the bind syntax would need to change to support it too. Lisa ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom Sent: Friday, June 01, 2007 9:45 AM To: Lisa Piper; john.havlicek@freescale.com Cc: sv-ac@eda.org; sv-bc@eda.org Subject: RE: [sv-ac] 22.10 bind review Thanks. That still has to be updated to Draft 3. Also, that Mantis does not deal with the 'variation' issue. Regards, Shalom ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Friday, June 01, 2007 4:35 PM To: Bresticker, Shalom; john.havlicek@freescale.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] 22.10 bind review This was fixed in SV-AC Mantis 1722 which has not yet been incorporated in draft 3. Lisa ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Friday, June 01, 2007 6:40 AM To: Lisa Piper; john.havlicek@freescale.com Cc: sv-ac@eda.org Subject: RE: [sv-ac] 22.10 bind review Also see thread beginning http://www.eda-stds.org/sv-bc/hm/5983.html . Shalom ________________________________ From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper Sent: Friday, June 01, 2007 1:29 AM To: john.havlicek@freescale.com Cc: sv-ac@server.eda.org Subject: [sv-ac] 22.10 bind review Hi John, I confirmed that the 22.10 Text on Bind was copied from Draft1 to Draft3 correctly. However, I also happened to notice that the Clause 16 description in section 1.6 (page 26) needs to be updated to exclude assertion binding. It should probably be added to the Clause 22 description as well. Another think that stands out now is that the title "Binding properties to scopes or instances" is not generic enough. Bind was moved because it does not have to only be used for assertions. Also, I noticed that Syntax 22-3 - Module item syntax replicates the bind directive from Annex A. Mantis 1722 added a note to the annex A bind syntax but did not note that this reference also needs to be udpated. The other changes of 1722 are not yet incorporated either. Perhaps we should open another Mantis item to change the title and not the note for Syntx 22-3. Lisa -- 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 <http://www.mailscanner.info/> 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 Thu Jun 7 10:08:09 2007
This archive was generated by hypermail 2.1.8 : Thu Jun 07 2007 - 10:08:26 PDT