Steven Sharp wrote: >>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? None from SV experience. But one point of using an OOP language is to set hooks capable of instrumenting any activity in the design. Program regions where side effects are entirely prohibited seem to degrade SV's generality as an object oriented way of working. If one's case labels are constant values of an OO data type, and you instrument the type's constructor to count how many are made, that's a (totally innocent) side-effect in a case label. I'm pushing SV's object-oriented envelope a bit, but C++ has "been here; done that", so I'm guessing SV is maybe a decade behind. > I think we can allow side-effects in the > case expression, just not in the case item expressions. Yes, the problem really only concerns the case label lists. > Since >99% of the time these are constants anyway. Yes, it is on the margin of the language, and few if any designs will be impacted. If case statements are the SUVs of programming, then unique case with side effect labels are Hummer stretch limos;-) The LRM would probably be just fine even if this issue is neglected entirely. > I don't see how this is impractical. A ban on Hummer stretch limos - is this practical or no? > 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. I'm with you there! Unique case was proposed to address serious mismatches between what simulators did with "case" and what designers wanted when they arranged for a one-hot bus to select the state transition function. When you asked what kind of evaluation order could compete with "top-down", I answered from a synthesis POV: We'd prefer to treat each guard and the sequential RTL it activates as a unit isolated from the other branches of the case. Because synthesis must already maintain distinct binding environments for each arm of the branch, it is natural to allow the guard to share that (speculative) address space. The trouble I fear is that this just takes more steps down the road of sim/synth mismatch. So I thought I'd describe this model and at the very least let it get shot down as "unsimulatable". If you can do that, I certainly won't be offended or hurt; sometimes the only route to consensus is to rule out the alternatives case-by-case until the unique answer is left standing (puns intended). Greg >>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.com >Received on Fri Feb 24 10:26:50 2006
This archive was generated by hypermail 2.1.8 : Fri Feb 24 2006 - 10:28:01 PST