S
server
Guest
message unavailable
M
Muhmmad Elrabaa
Guest
On Thursday, April 20, 1995 at 10:00:00 AM UTC+3, Kevin Normoyle wrote:
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!
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
exist.
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
-kevin
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!