Cliff & Don, The proposal for 1715 was only for .triggered method for a clocking block event, not any signal. For assertions, we already have $rose(clk). That could be extended to be used outside of an assertion to do what you want. Dave ________________________________ From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Don Mills Sent: Friday, May 04, 2007 9:48 AM To: Clifford E. Cummings Cc: sv-ec@server.eda.org Subject: Re: [sv-ec] Fwd: Cliff's Votes - E-mail Vote (part 2) Closes 12am PST May 2 2007 DM> I like what proposed for 1715. I want add a couple of comments and an alternate proposal: Cliff wrote: 1715 ___ Yes _X__ No I want to understand this need better before I vote yes. Is this enhancement being proposed because clocking_vars are triggered in the Observed Region? Don't we see those triggers in the Reactive regions with simple @(clocking_var) constructs? Isn't this similar to VHDL's var'event construct? Perhaps this should extend to other Verilog constructs. Example: always_ff @(posedge clk or negedge rst_n or negedge set_n) if (!rst_n) q <= '0; else if (!set_n) q <= '1; else q <= d; The above has the well-known problem that if rst_n and set_n are both asserted and if rst_n is removed first, the flip-flop, which should set the q output (because set_n is still low) fails to do so in simulation until the next posedge clk. But we cannot remove the negedge on the rst_n and set_n signals in the sensitivity list; otherwise, the flip-flop could assign data if rst_n is removed when set_n is not asserted (no rst_n and no set_n - therefore clock the d input without a clock signal). DM> I want to elaborate on this problem that Cliff just described. The model above is the how synthesis requires an asynchronous set/reset ff to be coded, however, this model has the corner condition error in Verilog simulation as Cliff described. The problem is, if we model the asynchronous set/reset ff so that it works on a Verilog simulator, then that coded model is not be accepted by synthesis. If we model it for simulation, then it fails synthesis. So the real problem that we need to resolve is to come up with a model that will both simulate and synthesize. I think Cliff's proposal is a very likely candidate for solving this dilemma. always_ff @(posedge clk or rst_n or set_n) if (!rst_n) q <= '0; else if (!set_n) q <= '1; else if (clk.triggered) q <= d; // else no change when rst_n or set_n are removed DM> I am not sure that always_ff is right (best) for this model since only one of the items in the sensitivity list has a posedge/negedge on it. Obviously, if this became the solution, then always_ff would have to be updated as well. Perhaps we can make this even more VHDL like: always @(clk or rst_n or set_n) if (!rst_n) q <= '0; else if (!set_n) q <= '1; // else no change when rst_n or set_n are removed else if (clk.triggered && clk == 1) // ensure that we had a transition to a 1 q <= d; Unfortunately, without the always_ff, be loose some of the built-in checking. Maybe there can be a way to pull these two concepts together??? Gotta have always_ff used somehow with this. Would solve the problem, if it were legal. Clifford E. Cummings wrote: Sorry - I forgot to copy this to the EC-reflector. Regards - Cliff Date: Tue, 01 May 2007 17:29:56 -0700 To: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.com> <mailto:Mehdi.Mohtashemi@synopsys.com> From: "Clifford E. Cummings" <cliffc@sunburst-design.com> <mailto:cliffc@sunburst-design.com> Subject: Cliff's Votes - E-mail Vote (part 2) Closes 12am PST May 2 2007 Cliff's votes summarized: See attached document for explanations. 1500 ___ Yes _X__ No 1556 ___ Yes _X__ No 1580 _X__ Yes ___ No 1608 ___ Yes _X__ No 1609 ___ Yes _X__ No 1612 _X__ Yes ___ No 1715 ___ Yes _X__ No ---------------------------------------------------- Cliff Cummings - Sunburst Design, Inc. 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and Verification Training ---------------------------------------------------- Cliff Cummings - Sunburst Design, Inc. 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and Verification Training -- ========================================================== Don Mills mills@lcdm-eng.com www.lcdm-eng.com ========================================================== -- 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 Fri May 4 11:09:53 2007
This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 11:10:03 PDT