>From: Greg Jaxon <Greg.Jaxon@synopsys.com> >Brad has often >suggested that SV prohibit side-effects here altogether, which would >probably not be practical for testbench uses; Can you give an example? I think we can allow side-effects in the case expression, just not in the case item expressions. Since >99% of the time these are constants anyway, I don't see how this is impractical. How often does someone use a variable in a case item expression, much less something that could have a side effect, like an increment or assignment operator or impure function call? They certainly don't belong in anything synthesizable. And since my understanding was that unique case was intended for synthesis, I don't think we should be worrying too much about them in testbenches anyway. Let's keep in mind what they are intended for, instead of just focusing on the construct itself. >Consider code where A,B,C,... stand for expressions or statements >whose evaluation order we wish to settle. > > unique case (A) > B, C : D; > E: F; > G, H: I; J; > endcase; > K; I will use your example to clarify what I said was unclear about "evaluating in order". I think you understood them, but others might not have. 1.If B is true, we don't have to evaluate C to know that the first case item was selected. It cannot affect which item is selected or whether the unique property was violated. Are we required to evaluate it anyway? 2.If B and E are true, we don't have to evaluate G or H to know that we have a violation of the unique property. We have already found at least one item to execute, and know we must produce a warning. Are we required to evaluate G and/or H anyway? I'm afraid I consider your "speculative execution" model to be far too impractical for simulation. If you want to ensure the semantics of parallel evaluation, then restrict the expressions to things that are not order-dependent. Steven Sharp sharp@cadence.comReceived on Thu Feb 23 17:49:24 2006
This archive was generated by hypermail 2.1.8 : Thu Feb 23 2006 - 17:50:47 PST