>From: "Michael (Mac) McNamara" <mcnamara@cadence.com> >Greg is right that it is only crazy cases where there is any order dependent effect in any case; but the corollary to that is the slow down would only be experienced in those crazy cases, and *gosh* those are the ones I want to spend simulation time on! This assumes that the simulator can statically detect those crazy cases, so that it doesn't slow down in other cases. If it could reliably detect those crazy cases, then we could make it illegal to have this kind of order dependency, and the problem would go away. But I don't think this is practical to detect in the general case. We could put restrictions in that would prevent it from happening, but people might not be happy with those restrictions. And as far as being willing to spend extra simulation time on those cases: we are talking about spending exponential amounts of time. So I doubt you really want to spend the simulation time on it in extreme cases. If the sun has burned out before you get your results back, they won't do you much good. BTW, defining a required evaluation order would avoid differences between simulators and give predictable results. However, it doesn't really solve the issue between simulators and synthesizers. Yes, the synthesizer knows the order the simulator used. But if the synthesizer is required to follow that order, then I think it defeats the purpose of "unique". As I understand it, "unique" was supposed to mean pretty much the same thing as "parallel_case". It tells the synthesis tool that it can evaluate these things in parallel. If it has to evaluate them sequentially to match side effects, then the purpose has been defeated. Note that any unique if/case that has an order dependency has inherently violated this intent of unique, by not being computable in parallel. So it could be considered an illegal unique if/case. The problem is how are you going to detect this kind of order dependency in the general case? Steven Sharp sharp@cadence.comReceived on Fri Jan 13 14:58:09 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 13 2006 - 15:00:02 PST