>From: "Rich, Dave" <Dave_Rich@mentorg.com> >[DR>] I said the default branch would not be a part of the priority >check. That means the check will *only* fail if it executes the default. Perhaps I misinterpreted part of what you said. I got the impression you had proposed: 1. That the default branch would not be a part of the priority check, so a failure occurs if none of the non-default items are chosen. 2. That a failure would not produce an error message, but would instead execute a user-defined action in the default clause (which might be to produce an error message, or set a flag to be tested in a concurrent assertion, or something else that allows user control of the conditions in which an error is produced). But this is equivalent to saying that if none of the non-default items are chosen, the default clause is executed. But that is what an ordinary case-statement does already, without any need to specify a priority case. Perhaps you intended that a failure produce an error *and* execute the default clause. I didn't interpret it that way because it would still produce the spurious errors. >> I am not convinced that a default is useless in a unique case. You >might >> have a default to handle a set of values that are too complex to >specify >> explicitly, but still want a failure if multiple explicit case items >> matched. >[DR>] >True, but I don't think a hardware designer thinks of having parallel >encoded logic as having a branch that's complex to explicitly specify. It sounds like you are saying that a parallel decode calls for a simple enough encoding that none of the cases should be too complex to explicitly specify. If one of the branches is defined as "didn't match any of the others", then it is inherently priority. Synthesis is outside my area, so I will take your word for it. I think the bigger problem is that this would not be intuitive. Based on the behavior of other cases, users would expect that a default will be executed when none of the other items match, not when several others match. Steven Sharp sharp@cadence.comReceived on Fri Apr 8 16:03:59 2005
This archive was generated by hypermail 2.1.8 : Fri Apr 08 2005 - 16:04:09 PDT