Subject: RE: [sv-bc] Enhancement Request: 2-state wildcard for case-items (in case, casez, and casex)
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Dec 08 2003 - 22:28:21 PST
Dave,
This suggestion sounds useful.
Will you be making a proposal to add "inside_expression"
to the BNF for case statements?
Thanks,
Doug
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Dave Rich
> Sent: Sunday, December 07, 2003 1:40 PM
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Enhancement Request: 2-state wildcard
> for case-items (in case, casez, and casex)
>
>
> Here is a link to the paper, it was not attached to Karen's
> message because it was too big
> http://www.arm.com/pdfs/Verilog_X_Bugs.pdf
>
> Mike,
>
> Instead of making assignments to X in the default, why not make the
> assignment before the case statement?
>
>
> Also note that the SV-BC has just passed a modification to
> the 'inside'
> operator, that has unidirectional (or asymmetric) don't care
> semantics.
> Synthesis tools should be able to read in code using the
> inside operator
> as long the operands on the RHS are literal values. This
> means that the
> LHS will only match 0s and 1s.
> See http://www.eda.org/sv-bc/hm/att-1308/01-inside.pdf
>
> The '*' character won't work because 3'b1*1 is already a
> legal expression
>
> What I would suggest is a case statement that has the same
> semantics as
> the inside operator, including the ranges.
>
> always_comb begin
> out = 'x;
> unique case inside(expr)
> 4'b???1 : out = 1;
> 4'b??1? : out = 2;
> 4'b?1?? : out = 3;
> 4'b1??? : out = 4;
> 4'b0000 : out = 0;
> endcase
> end
>
>
> Karen Pieper wrote:
>
> > The following mail is from Mike Turpin of Arm. It bounced
> because he
> > is not a member of the
> > mailing list.
> >
> > Karen
> >
> > <Mail from Mike Turpin>
> >
> > Hi,
> > I just read an EETimes article on SystemVerilog and this
> prompted me to
> > make an enhancement request, to allow a new 2-state
> wildcard symbol for
> > case-items (maybe "*").
> > Many designers use X in casex-items or Z/? in casez-items as
> > wildcards, as
> > they cannot use normal case statements (there's no wildcard
> here). The
> > designers intent is normally to match incoming 2-state (0 or 1)
> > combinations - but the casex/casez wildcards also match
> incoming X's
> > (which
> > can be dangerous).
> > I've attached a paper I've written on X-issues in Verilog -
> which won an
> > award at Boston SNUG 2003. One of it's key recommendations is that
> > X-propagation in case-defaults has to be more sensible than
> optimistic
> > X-termination. Another argues against ever using casex and
> only using
> > casez
> > with care.
> > Here's an example. You need to code a case statement that's
> got a 32-bit
> > case item and you only want to specify a few combinations
> as assigning
> > 1'b1
> > - with the rest assigning 1'b0. Using a standard
> case-statement, the 2^32
> > combinations means that it's only practical to use the default to
> > assign 0
> > rather than X - which could cause simulation vs synthesis
> differences (if
> > don't-care X's get minimized to a specific case-item that
> would assign
> > 1'b1, then the netlist simulation differs to the RTL simulation).
> > With a "*" 2-state wildcard you could have separate 2-state
> and 4-state
> > case defaults, e.g.:
> > case (sel)
> > ... // case-items assigning X
> > 32'h****_****: o1 = 1'b0; // New wildcard allows 2-state default
> > default: o1 = 1'bX; // X-propagation
> > endcase
> > This 2-state wildcard would also allow more obvious
> priority encoders
> > in a
> > case statement, e.g.:
> > case ({w1, w2, w3})
> > 3'b1**: o2 = i1; // w1 has highest priority
> > 3'b01*: o2 = i2;
> > 3'b001: o2 = i3;
> > 3'b000: o2 = 2'b00;
> > default: o2 = 2'bXX; // X-propagation
> > endcase
> > This above form avoids the use of nested if-statements (which are
> > dangerous
> > as they handle X's optimistically as 0).
> > I'd like to propose a 2-state wildcard for case, casez and
> casex - with
> > some recommendations on it's use over the existing wildcards. I'd
> > appreciate any feedback on this.
> > One last thing, I'm not sure why the SystemVerilog 3.1a LRM states
> > that you
> > don't need to specify a default when you use
> unique/priority prefixes.
> > I'm
> > not sure of the simulation semantics for these, but it
> would be good
> > to see
> > a recommendation to enable X propagation.
> > Regards,
> > Mike
> > _____________________________________________________________
> > Mike Turpin Tel: +44-1223-400459
> > Principal Verification Engineer Eml: Mike.Turpin@arm.com
> > CPU Verification
> > ARM, Cambridge, UK
> >
> >
>
> --
> --
> David.Rich@Synopsys.com
> Technical Marketing Consultant
> http://www.SystemVerilog.org
> tele: 650-584-4026
> cell: 510-589-2625
>
>
>
>
This archive was generated by hypermail 2b28 : Mon Dec 08 2003 - 22:29:38 PST