Sytem Verilog one-hot selection

If they are supported by the tools, then they probably would do that. But they might not yet supported by the tools (presumably Altera quartus_map in this case), or might not be supported by the tool version that you have.

They do are supported, I'm using Quartus 7.2. At least both the help and the manual claim they are supported. Some tests indicate it correctly infers "parallel" cases thanks to the "unique" keyword. But it doesn't seem to infer a "full" case.

Looks like Quartus II only implements the parallel_case semantics of the unique keyword and not the full_case. To me, it's not natural for unique and priority to imply full_case, even though the LRM does define it that way. The tool probably considers it safer to avoid relying on the full_case implication. Sure, it misses an optimization, but it also avoids an unintentional change to the design semantics. If the LRM had made it an error rather than a warning to have a case value that's not covered by an explicit case item, then it would be easier to utilize the full_case semantics. The LRM should have defined a full keyword to avoid all this confusion. :)

Hi HDL Guru,

The latches are an attempt to match what would actually happen during simulation if your case expression didn't match an explicit case item. Your variable would hold its previous value. In that sense, Altera is simply trying to match the simulated behavior of the design as much as possible. They aren't simply tossing the standard aside flippantly; they are preserving the defined semantics of the design. They chose to require you to use the full_case attribute to force the potential simulation/synthesis difference.

Hi,

This is a good discussion!

module unique1(input  sel, input a, b, c, d, output reg o);
   always_comb
	 begin
		o = d;
		unique case(sel)
			2'b01: o = a;
			2'b10: o = b;
			2'b11: o = c;
 	      endcase
	 end
endmodule

It is true that Modelsim 6.2 doesn't support "unique". You can't help it if you use features unsupported by the tools. Possibly (hopefully) Modelsim 6.3 does. At least it mentions additional SV support.

According to the SV LRM, a tool can issue a warning if the case expression doesn't match a case item in a unique/priority case. That's it. It says nothing about assigning a "don't-care" value to all the variables assigned inside the case statement (and what about two-state variables that don't have x/z?) The variable will hold its previous value, i.e. the LRM says nothing about the keyword changing the simulation semantics. So I'm sticking to my guns here and calling it a flaw. :) It would be one thing if the LRM made a proclamation about synthesis behavior, but it only discuses simulation behavior.

True, the LRM doesn't say it should assign X, but it doesn't say it can't or it shouldn't. I definitely would expect it would assign the unknown/undetermined value. Because that's exactly the situation, and that's what would match a synthesis behavior that followed the standard. In other words, the simulator can't know or predict what would happen at the hardware. The value is simply unknown.