Subject: Re: [sv-bc] Enhancement Request: 2-state wildcard for case-items (in case, casez, and casex)
From: Dave Rich (David.Rich@synopsys.com)
Date: Sun Dec 07 2003 - 13:39:35 PST
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 : Sun Dec 07 2003 - 13:40:27 PST