??? 10/17/07 17:49 Read: times |
#145858 - re: a noob question Responding to: ???'s previous message |
Maarten Brock said:
case (in) 8'b00110001: out = 2'b01; 8'b10101100: out = 2'b10; 8'b11110101: out = 2'b11; default: out = 2'dx; endcaseSince apparently 2'dx here means unknown instead of don't care, what happens if you leave out the default case? Would that qualify as don't care about the output for unspecified inputs? Simple answer: For synthesis, you should NEVER assign an unknown. The tools should complain. Lemme say that again: UNKNOWN is NOT the same as don't-care. Never assign an unknown if your design is meant to be synthesized. This is something about which all of the Verilog gurus agree. Think about it. What if the logic that uses out cares about its value? For instance, when out is 2'b00, it does a particular thing, when it is 2'b01, it does some other particular thing. Now you say that if in doesn't match any of the three specific cases, then the tool can do whatever it wants to out. Now there's no such actual electronic value as an unknown, so the synthesizer is free to choose whatever it wants. What if it chooses 2'b00? Well, in didn't match the requirements to assign out to 2'b00, yet there it is. Sounds like a recipe for disaster to me. Regarding latching: If you put this case statement in a synchronous process, that is, within the always @(posedge clk) block, then if you leave out the default case, you're fine. The output will not change if your inputs do not match any of the specified cases. The synthesizer will build some kind of minimal logic using the clock enable and the D input to the two flops. If you put this case statement in a combinatorial process, that is, within the always @(this, that, theother) block, then if you don't supply a default case, or if you don't specify all possible cases, the synthesizer will build a latch because it must somehow retain the previous value. When the tools build such latches, they will complain and you should reconsider your code. The solution with casex and specifying which input bits are don't care places the burden on you to reduce the logic where I would expect the tool to do that for me. Huh? No. Really: No. As I pointed out to Russ, the case statement has to explicitly match the patterns specified. If you specify only three cases out of 256, and those three cases are very different (as in Russ' example) then the tool will go, "Oh, all three of your cases are mutually exclusive so I must check everything." Another, simpler example, should make this clear: case (in) 4'b0000 : out = 2'b00; 4'b0001 : out = 2'b01; 4'b0010 : out = 2'b10; 4'b0011 : out = 2'b11; endcaseThink about this. You can look at it and think, "Oh, all you need to do is copy the two LSBs of in to out and you're done." But you'd be horribly WRONG. Why? Because you've only specified four out of the possible 16 cases. When the input is 4'b1000, what happens? Dunno! You didn't specify. The world could end. -a |