• x's and don't cares in verilog?

    From Muhmmad Elrabaa@21:1/5 to Kevin Normoyle on Sat Oct 17 06:06:44 2020
    On Thursday, April 20, 1995 at 10:00:00 AM UTC+3, Kevin Normoyle wrote:
    Are x's don't cares or illegals? Big question.
    It's sort of a big-endian/little-endian pc/mac etc/etc. thing
    for this kind of group.
    The problem is that historically x's have been overloaded
    with two meanings. And we're suffering because of that.
    X propagation for illegal operations was important for gate
    level simulators, where the idea of behavioral monitors didn't
    But now that we can stop the simulation whenever anything bad
    happens (with appropriate monitor code), we shouldn't rely
    on propagating x's to a "visible" pin or something, to make
    illegal operation halt the simulation.
    You can't be sure that x propagation happens correctly thru behavioral code (it usually doesn't and you can't be sure that you'll stop on the x....
    some x's are okay...and it can be hard to validate an "illegal x" way far down
    the activity chain. (because it's in a different context)

    So I'd vote for consistently using x's for don't cares, and
    develop another method for making sure you detect all illegal
    cases. There's no common wisdom, though.
    But if you're using someone else's libraries, they may rely
    on x propagation for illegal operation detection...oh well.
    Once you get the hang of it, you'll realize that you can detect
    all sorts of "architectural" problems with monitors, that you ordinarily wouldn't
    have thought of detecting through an "x propagation" solution.
    But you can make x mean anything you want....
    I speak for all asic designers from 1920-1930 :)

    Actually, the problem is very clear and the solution could be very simple. In the Verilog standard, x is 'unknown', so before synthesis, a simulator would actually give x for an output that was assigned x. Synthesis tools however, came to consider x as
    don't care, i.e. the synthesis tool may set the value to 0 or 1 (or try both and see which simplifies the logic more) and simplify the logic. Post synthesis simulation would yield the value selected by the synthesis tool, and it won't be x. One can
    always take that value and back annotate it in the original Verilog code instead of the original x value and get a matching simulation behavior

    In circuit design, such situations arise a lot -- the solution is always back annotation .. e.g. to size gates in an ASIC design flow, we need to estimate the wire lengths (they represent part of the load), but we won't get those lengths till we size,
    place, and route our gates. So do an initial estimation, size, place, and route, get the wire capacitances, backannotate it in the original netlist, re-size, re-place, and re-route .. wala!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)