Sytem Verilog one-hot selection

[Altera_Forum]

Aren't the new System Verilog case specifiers (unique/priority) supposed to avoid the need of using the synthesis attribute "full_case" ? 

 No matter what I do, I cannot get a one-hot optimized selection unless I add the full_case attribute.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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. :)

[Altera_Forum]

Hi HDL Guru, 

 I'm not sure I follow your logic. Yes, I might agree that the term "unique" might not be the best choice to imply a full case. But like it or not, that's the standard. And it doesn't make much sense to me that Altera would, on purpose, go against the standard because it doesn't like the keywords selected by the standard.  It seems more like a bug. If Altera would prefer an "unique" behavior for the "unique" keyword, then at the very least this should be clearly documented (I would actually add a configuration option).  And I'm not sure it is safer. It is not just an issue of missing an optimization. It infers latches.

[Altera_Forum]

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. 

 If the LRM had made it an error to have a case expression value that didn't match an explicit case item, then we might have a different story.

[Altera_Forum]

Hi, 

 I know you are much more expert than me, but please, I beg to differ once again.  In first place I assume you are just guessing about Quartus doing this on purpose and not being a bug. Or do you have some internal info about this?  And again, even if that is the case, I would expect this to be explicitely documented, may be even to issue a warning.  I don't think the latches are for the purpose of matching the simulation. The latches are a direct consequence of not inferring a full case. There is no need to infer latches to match simulation, because most simulators (hopefully) will follow the SV LRM standard. I guess this is not the whole industry going against the standard, or is it ? :)  It doesn't make any sense to force you to use synthesis attributes for accepting a potential difference with synthesis and simulation. The whole point of the SV unique keyword is precisely to avoid this difference. It is a language keyword, not an attribute. Both synthesis tools and simulators would (should) see it.  I don't see why you are saying they are preserving the "defined" semantics of the design. The semantics are defined by the standard and by the implementation documentation. Not by what you and me (or Altera for that matter) might like. So I would say that the defined semantics is a full case.

[Altera_Forum]

This is a good discussion!  

 Let's focus on the simulation side. How exactly would a simulator honor the full_case implication of the unique/priority keywords? Here's an example:   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   What would happen in simulation if sel == 2'b00? I ran this example in Modelsim 6.2f SE but it gave me the following:   # ** Warning: unique1.v(6): (vlog-62) SystemVerilog keyword 'unique' is not currently supported.  Still, what would you expect to happen if a simulator supported the unique keyword, i.e. what value should o have after executing the case statement. Seems like it should be o == d, which is exactly how it simulates in Modelsim without unique support. I ran the example in Quartus II 7.2 SP1 and, in fact, it matches Modelsim.   Seems like it's a flaw in the standard. If a synthesis tool honors the full_case implication of unique/priority, it creates the possibility of a simulation-synthesis mismatch. True, the same argument applies to the primary meaning of unique/priority, too! But the primary meaning is more obvious, I feel. I understand that unique means parallel_case and priority means no parallel_case. But it's not obvious that unique and priority both imply full_case, so it's more dangerous for a synthesis tool to rely on that implication, i.e. because it may not be a legitimate expression of the designer's intent. For sure, the unique/priority keywords do absolutely nothing to change the semantics of the case statement in simulation.   The SV standard should have made it an error for a unique case statement to have overlapping case items and for a unique/priority case statement to be incomplete, e.g. have a value for the case expression that doesn't match a case item.  I do agree with you that Quartus II should be clear that it ignores the full case implication, for it currently issues this warning for my example:  Warning (10270): Verilog HDL Case Statement warning at unique1.v(6): incomplete case statement has no default case item

[Altera_Forum]

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. 

 A simulator supporting the "unique" keyword would, at the very least, give a run-time warning. This alone by itself is much more than using the synthesis full_case attribute, which will be completely ignored by the simulator.  And the value assigned would be 'x', if you wouldn't have included the (o = d) assignment previous to the case statement. You included it because otherwise Quartus would infer a latch, which is forbidden by the always_comb block. But if Quartus would fully support "unique" as per the standard, it would infer a full case, and then no previous assignment would be needed.  So this means that the keyword does change the semantics under simulation. At least at the extent of assigning X, and not the previous value.  I don't see this as a language flaw. I agree that the "unique" word might be a bit misleading. But this is not the only case in Verilog (and almost every language has some of those), and I wouldn't qualify this as a flaw.

[Altera_Forum]

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.  

 Still, I imagine Altera and most other vendors will follow the general consensus among users. I'd file a service request if you feel strongly about the issue. You have a point - for the savvy user, it's annoying that Quartus II won't assume full_case for unique/priority case statements. The logic of, "Well, it may cause a simulation/synthesis mismatch and people may not be aware" isn't exactly compelling to me and I'm the one making the argument. :) I re-iterate my point: it would have been better for the LRM to make it a run-time error.

[Altera_Forum]

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. 

 If you are using 2-state types (such as bit), then of course it won't assign X. It is your responsability if you decided to use an "unsafe" type in a potentially "dangerous" situation. Unsafe in the sense that it's a type that has less chances to spot errors under simulation. This is not specific to the "unique" keyword. Anytime you use a 2-state type, you lost the chances of catching an 'X'.  In the worst case, you still get a warning, which is light years better than nothing as you get when using the full_case synthesis attribute.

[Altera_Forum]

I received a reply from "MySupport" claiming that "unique" is not supported and it is ignored. This can't be 100% true because you get additional warnings when using the keyword with overlapping case items, and the warnings do reference the System Verilog "unique" feature. 

 I guess the conclusion is that it is supported by the earlier analysis, parsing phases, but it is ignored at actual shyntesis.  I also checked the ModelSim 6.3 release notes and both "unique" and "priority" are now supported. I hope Altera will update their ModelSim version with newer QII releases (and of course, add full support for the keywords in Quartus as well).

[Altera_Forum]

MySupport gave you the wrong info. If you look at Quartus II Support for SystemVerilog 2005 in online Help in Quartus II 7.2: 

 IEEE Subsection Construct Description  10.4 Selection statement Supported (unique/priority supported only on case statements)  I compiled my previous example (without the o = d) in Modelsim 6.3c SE. If sel == 2'b00, then I see the following warning:  # ** Warning: (vsim-8315) unique1.v(5): No condition is true in the unique/priority if/case statement.  As expected, o holds its previous value.

[Altera_Forum]

Hi HDL Guru, 

 I know the online help (and the full manual as well) claims they are supported. I mentioned this already at one of my first posts. But how do you know MySupport is wrong, and not the manual and online help are the ones that are wrong?  I made a couple of tests and it seems indeed the manual is wrong. Not even the parallel semantics seems to be supported (I initially thought the problem was only the full semantics). All you get is some additional warnings at compile time (but not at simulation run-time).  Thanks for testing under ModelSim 6.3. So I was wrong about that. I still think it's not the right simulation behavior. The simulator knows there are no latches, so I don't understand why it preservers the previous value.

[Altera_Forum]

I guess I trust the documentation that ships with the tool rather than a support hotline. :)  

 Hey, you're right! I played around with some nasty non-parallel case statements. Quartus II 7.2 doesn't force parallel implementation. It just gives you a warning about having overlap in a unique case statement. From the looks of things, Quartus II is implementing unique/priority more as an assert about a design property than a direction to implement the logic in a particular way. That's not terribly useful.  I think I'm coming around to your way of seeing things. Personally, I would have preferred that SystemVerilog introduced an equivalent full keyword rather than making unique/priority absorb the semantics. Then I started thinking, these keywords are really just intended to give designers the same semantics as parallel_case, full_case but with some modicum of simulation support. A warning in simulation is better than nothing, as you said.

[Altera_Forum]

Finally, Quartus version 8.0 fully supports the SV "unique" keyword in case statements. At least for synthesis, didn't check the Quartus simulator. 

 Seems to be one of the many new SV features in 8.0, and it is not mentioned in the "what's new" doc. Another very useful new SV feature (undocumented as new) is support for implicit port connections.  I wish Altera would make a comprehensive list of new features in 8.0