Re: [sv-ec] Fwd: Cliff's Votes - E-mail Vote (part 2) Closes 12am PST May 2 2007

From: Don Mills <mills_at_.....>
Date: Fri May 04 2007 - 09:47:38 PDT

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>
From: "Clifford E. Cummings" <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, and is
believed to be clean. Received on Fri May 4 09:52:36 2007

This archive was generated by hypermail 2.1.8 : Fri May 04 2007 - 09:53:08 PDT