( ESNUG 242 Item 6 ) ---------------------------------------------- [7/11/96]
Subject: (ESNUG 240 #7) Synchronous Reset Thru An ALU Still Gives Xes!
> I've run across another "FEATURE" of Synopsys that has landed me into a
> large heap of Sheep DIP! I have a design that has a number of registers
> that are all fed by a simple ALU. Rather than have all of the registers
> use an asynchronous reset (at a cost of 1-2 gates per D FF), I simply have
> the ALU perform the following operation:
>
> 0 "AND" X
>
> And then load the resulting 0 in all of the registers by simply enabling
> all of their clock enables. Now, 0 "AND" X normally would produce 0 on
> any output of the ALU. After all, 0 "AND" *anything* should be 0, right?
> -- well, *not* according to Synopsys! I still get Xes out of my ALU!
> Naturally when I try to run my gate-level simulation I never even get out
> of reset! From reading various SOLVIT, app notes and online docs, I see
> where I could add the attribute sync_set_reset if there were some registers
> to attach it to. But since the block in question is purely combinitorial,
> what can I do?
From: Bruce Nepple <bcn@ccm.seikotsi.com>
John,
Regarding Eric being in sheep dip, I suspect that there are an awful lot of
"unneeded" logic gates in the world just to get around simulators that can't
deal logically with unknowns (this *is* a simulator issue, not a design
compiler issue). Maybe someday a simulator manufacturer will see unknown
resolution as a competitive edge (saves gates and time). The situations
where I seem to get nailed are best represented by multi-stage synchronizers
that feed-back to reset the input FF (always zero after a couple of clocks,
but always X in Verilog-XL) and logic that effectively creates 0 or 1 with
0 = A & ~A or 1 = A | ~A (always 0 or 1 in the real world, but will propagate
X's like sheep dip through a flea farm). The latter case can be spread over
many gates, and is probably what is happening to Eric. I've always solved
these either by adding gates (async. resets or whatever) or by using the
"force" function in verilog (rah rah verilog) to force critical internal
pins to zero for the first cycle. I've actually added an unused reset
pin to an IC just for simulation and fault grading. Again, I don't blame
the design compiler.
- Bruce Nepple
Seiko Communications Systems
---- ---- ---- ---- ----
From: Michael_Armstrong@BayNetworks.COM (Michael Armstrong)
John, I don't think this issue is as simple as it seems.
A simple example that sheds some light on this question is the following:
If I have a 2-input multiplexer with zero's on both inputs and an 'X' on the
select line, should I get a zero out? The answer is probably yes, but most
models of the multiplexer would put out an 'X' if the select line is unknown
regardless of the inputs instead of handling the special case of all inputs
being zero (or one, for that matter). Just think if you had a 64-input
multiplexer - should the model look for all 64 inputs to be low and handle
that special case? It might be technically correct to do so, but I think
most models would not bother. In some cases the 'X' would be the better
answer; if the select line was metastable and was not at a legal logic level,
then the output would be unknown.
- Mike Armstrong
Bay Networks
---- ---- ---- ---- ----
From: dj@lsil.com (Darren Jones)
Hey John,
In an ALU we designed, we have a similar problem. The reason in our case was
that the ALU was implementing the AND function using XOR gates (I won't go
into the gate-level details.) It ends up that if the first operand is 0, the
logic XORs the second operand with the inverted second operand. Obviously,
this would always have a result of zero in real silicon, but in simulation,
if the second operand is X, its inverted value is also X and the function
ends up with an X as a result!
In our case, it was only a problem with the structural model -- the RTL model
works fine. One solution was to change the order of the operands -- instead
of "0 AND X", try "X AND 0". I doubt that this is something Design Compiler
would be able to figure out.
- Darren Jones
LSI Logic
|
|
