I have found every proposed version of trying to describe this 4-state if-else behavior using existing operators to be non-intuitive. From a user's perspective, the combination of operations proposed only muddies the water and makes the decision result impossible to understand. The KISS principle needs to be applied here. Why not use a simple truth table, similar to what is used to describe Verilog 1-bit gate-level results? Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL, Inc. stuart@sutherland-hdl.com 503-692-0898 > -----Original Message----- > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] On Behalf Of John Havlicek > Sent: Wednesday, May 02, 2007 9:37 AM > To: doug_warmke@mentor.com > Cc: Brad.Pierce@synopsys.com; sv-ac@server.eda-stds.org > Subject: Re: [sv-ac] if..else and 4-state conditions > > Hi Doug: > > Our objective is to find a way to describe the relevant > enabling conditions in terms of existing SystemVerilog > operators. This is because we want to define the enabling > condition as a rewrite. > > The first criterion is that the semantics of the rewritten > condition be correct (i.e., aligned with Verilog 4-state > if..else and case selection semantics). > > We had a simpler rewrite for the enabling condition of > the "else" in "if (b) .. else ..", namely "!b", but this > rewrite has the wrong 4-state semantics. > > Do you have a simpler representation in mind? > > J.H. > > > > > Hi All, > > > > Personally I find these expressions clever, but they will be > > considered "obfuscated" by most readers. I suggest we strive > > for something obviously correct at first sight to all readers, > > not just experts. > > > > Thanks, > > Doug > > > > > -----Original Message----- > > > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] > > On Behalf Of Brad Pierce > > > Sent: Wednesday, May 02, 2007 7:29 AM > > > To: sv-ac@server.eda-stds.org > > > Subject: Re: [sv-ac] if..else and 4-state conditions > > > > > > >what is the meaning of > > > > 1'b0 inside {1'bx} > > > > > > It's 1'b1. > > > > > > The following are the same -- > > > > > > 1'b0 inside {b!=0} > > > 1'b0 ==? (b!=0) > > > > > > The ==? propagates unknowns from the left, but treats > unknowns on the > > > right as optimistic don't-care wildcards > > > > > > RIGHT > > > 0 1 x z > > > > > > L 0 1 0 1 1 > > > E 1 0 1 1 1 > > > F x x x 1 1 > > > T z x x 1 1 > > > > > > -- Brad > > > > > > -----Original Message----- > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of > > > Jonathan Bromley > > > Sent: Wednesday, May 02, 2007 5:01 AM > > > To: sv-ac@eda-stds.org > > > Subject: RE: [sv-ac] if..else and 4-state conditions > > > > > > Apologies, I mistakenly sent this response to Brad Pierce > instead of > > > sv-ac at first. > > > > > > ~~~~~~~~~~~~~~~~~ > > > > > > > A simpler way to write that condition is > > > > > > > > 1'b0 inside {b!=0} > > > > > > Urrrm, what is the meaning of > > > 1'b0 inside {1'bx} > > > ? > > > > > > Actually, my original suggestion was (almost) > > > > > > (b!=0) !== 1'b1 // originally I forgot the 1'b size > > > > > > which seems to me to be simpler still; but I > > > (willingly) conceded that !bit'(b!=0) was neater. > > > > > > Surely the point here is that we need two expressions that are > > > guaranteed to be (a) 2-state, (b) complements; both > > > bit'() , !bit'() > > > and > > > ===1'b1 , !==1'b1 > > > fit the requirements in a rather obvious way. > > > -- > > > Jonathan Bromley, Consultant > > > > > > DOULOS - Developing Design Know-how > > > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > > > > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, > Hampshire, BH24 > > > 1AW, UK > > > Tel: +44 (0)1425 471223 Email: > > > jonathan.bromley@doulos.com > > > Fax: +44 (0)1425 471573 Web: > > > http://www.doulos.com > > > > > > The contents of this message may contain personal views > which are not > > > the views of Doulos Ltd., unless specifically stated. > > > > > > -- > > > This message has been scanned for viruses and dangerous content by > > > MailScanner, and is believed to be clean. > > > > > > > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, 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 Wed May 2 10:20:02 2007
This archive was generated by hypermail 2.1.8 : Wed May 02 2007 - 10:20:21 PDT