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

From: Rich, Dave <Dave_Rich_at_.....>
Date: Fri May 04 2007 - 11:09:26 PDT
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