( ESNUG 337 Item 3 ) -------------------------------------------- [11/18/99]
Subject: ( ESNUG 334 #2 ) full_case/parallel_case, Evil Twins of Synthesis
> But Cliff also says (in 3.3) that using a default: out = 'bx; also isn't
> good because then your simulation & synthesis don't match.
>
> Here I disagree. I think you're trying to optimize the wrong part of
> the design: simulation vs. gates match. In doing so, you're giving up
> some of the power of RTL simulation. In RTL I'm able to write code
> in such a way that my logic will blow up to X's when a make a false
> assumption. (i.e. I *believe* the case to be fully specified, if it's
> not, I want X's introduced into my sims, not some latch function or
> other valid input - X's are easy to detect and trace back)
>
> In my opinion the power and usefulness of inserting X's to detect designer
> failure in RTL outweighs the fact that synopsys will never "create" an
> X from gates.
>
> - Paul M Gerlach
> Tektronix, Inc. Beaverton, OR
From: "Harry Foster" <foster@rsn.hp.com>
Hi, John,
I read with interest the discussion concerning X-state assignments in the
RTL design. I believe that using the X-state at the RT-level is a bad
idea -- even without the performance penalty that it causes in simulation
and equivalence checkers and the fact that pre-synthesis vs. post-synthesis
simulation runs may differ as Cliff points out. RTL simulation using the
X-state can be both excessively pessimistic and optimistic, and attempts to
over-come these shortcomings are impractical.
Consider X-state pessimism -- an arithmetic operation is one example of
gross pessimism in X-state RTL simulation.
reg [15:0] a,b,c;
...
begin
b = 16'b0000000000000000;
c = 16'b000000000000X000;
a = b + c;
$display(" a = %b",a);
end
The result for "a" in a four-state Verilog simulator will be
a = XXXXXXXXXXXXXXXX
At the cost of reduced simulation performance, a Verilog gate-level
simulation can more accurately handle this addition, resulting in
a = 000000000000X000
More insidious, however, is the way that RTL simulation of 'case' statements
and 'if-else' statements with an X-state can lead to optimistic results, and
thereby hide real start-up / initialization problems in a design.
For example, given an XX as the start-up state for "d", the "case" will
always take the "default" branch. Hence, this will only test one of the
four possible branches that the start-up condition could actually take, if
we consider the four possible two-state interpretations of the XX bits.
reg [1:0] d, e;
...
begin
case (d)
2'b00 : e = 2'b01;
2'b01 : e = 2'b11;
2'b10 : e = 2'b10;
default : e = 2'b00;
endcase
$display(" e = %b",e);
end
The result for "e" in a four-state Verilog simulator will be that "e = 00"
whenever "d" contains an X.
It is possible to code the RTL in a style which would intercept and process
X-states more accurately, moderating both the pessimism and the optimism.
For example, our case statement could be modified to intercept X-states and
propagate their affect on the result more accurately.
reg [1:0] d, e;
...
begin
case (d)
2'b00 : e = 2'b01;
2'b0X : e = 2'bX1;
2'b01 : e = 2'b11;
2'bX0 : e = 2'bXX;
2'bXX : e = 2'bXX;
2'bX1 : e = 2'bXX;
2'b10 : e = 2'b10;
2'b1X : e = 2'bX0;
2'b11 : e = 2'b00;
endcase
end
This coding style quickly becomes unmanageable for all but the simplest
examples and is prone to errors (incompleteness). In addition, we are very
quickly loosing the designer's clear functional intent to support an
irritating consequence of RTL X-state simulation.
I agree with Cliff concerning pre- vs. post-synthesis simulation
consistency. In general, an RTL coding style and set of tool directives
must be selected which insures semantic consistency between simulation,
synthesis and formal verification tools. This is a fundamental principle
of verifiable RTL design, which I call the "Faithful Semantics Principle."
- Harry Foster
Hewlett-Packard Computer Technology Lab Richardson, TX
|
|
