Date: Thu Feb 22 2007 - 06:42:35 PST
On second thought, why is mentioning synthesis bad in this case and not in Clause 11 of the current LRM? e.G., 11.4 Sequential logic The SystemVerilog always_ff procedure can be used to model synthesizable sequential logic behavior. For example: always_ff @(posedge clock iff reset == 0 or posedge reset) begin r1 <= reset ? 0 : r2 + 1; ... end The always_ff block imposes the restriction that it contains one and only one event control and no blocking timing controls. Variables on the left-hand side of assignments within an always_ff procedure, including variables from the contents of a called function, shall not be written to by any other process. Software ... Is it only in respect to the regular always block where you see a problem? Regards, ed ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Thursday, February 22, 2007 7:58 AM To: Eduard Cerny; sv-ac@eda-stds.org Subject: RE: [sv-ac] Mantis 1674 proposal - Inferred value functions Define it as you wish as long as a simulator can implement the specification. Simulators don't understand synthesis. Shalom ________________________________ From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] Sent: Thursday, February 22, 2007 2:56 PM To: Bresticker, Shalom; sv-ac@eda-stds.org Subject: RE: [sv-ac] Mantis 1674 proposal - Inferred value functions Hi, I guess we'll have to write it only by referring to the form of the event expression. Would that work? ed ________________________________ From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, February 22, 2007 4:45 AM To: sv-ac@eda-stds.org Subject: [sv-ac] Mantis 1674 proposal - Inferred value functions Hi, I glanced over the proposal for Mantis 1674. I see that it says, "The disable condition can only be inferred from a synthesizable synchronous always block with asynchronous reset or from always_ff with asynchronous reset." This statement is problematic. The LRM does not define anywhere what is synthesizable, and rightly so, because 1. This is not a standard for synthesis. 2. What is synthesizable is constantly expanding. 3. What is synthesizable varies from tool to tool. I don't think this statement can remain as it is. Regards, Shalom Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 -- 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.
