>Steve raises interesting points, which I belive apply to all assertions, >clocked or immediate (I am hoping for assertion comment from Arturo and Adam). > >I believe all the points raised by Steve apply equally to assertions, and I >think they are just the nature of assertion-based design, one that needs to >be taught to engineers. Sampled assertions can obviously miss between-clock >events and multiple calls to the same function leaves us with the last >function-call values, because assertions evaluate in different regions from >RTL code. There is not an inherent problem with assertions. They work the way they are defined to work, and it is up to the engineer to understand that and how to use them to accomplish what they want. That may include choosing between immediate and concurrent assertions as appropriate for the task. The problem with trying to apply this to priority/unique case is that these are inherently immediate assertions. They execute at a specific point in procedural code, only if and when execution reaches that point, and use the current values of objects (including temporary variables that may have been computed just before and change immediately after). What you are trying to do is convert these automatically into concurrent assertions. These concurrent assertions are supposed to be equivalent except that they don't produce certain types of failures you consider to be spurious. I don't see how this transformation can be performed in general. The most practical approximation for the situation you describe would be to wait until the observed region and then produce an error only if the most recent evaluation of the priority/unique if/case violated the assumptions. As noted, this can miss real failures when used in loops or functions. It also won't filter out glitches that are not zero-width (which I assume comes up with the NBAs with #1 delays that you mentioned). >Steve accuses me (it's okay Steve!) of trivial RTL coding examples, when in >fact, I discourage many of the problem areas he notes below (and I am >feeling even better about discouraging their use now ;-) We have different viewpoints. This sort of thing occurs a lot with language extensions proposed by users. You plan to use them in a certain way, and don't worry about what would happen if they were used in a way you don't plan on. You can write your code avoiding any situations you don't like. As an implementor, I have no control over the source code my implementation has to handle. I need a definition of how all possible input source code is supposed to behave, not just the things you have in mind. >Steve's proposal to generate the warnings iteratively and on the fly within >the same time step should indeed catch all problems ... along with a myriad >of non-problems. It isn't my proposal. It is how the LRM says they work. This idea that they are checked at a time other than when the if/case is executed seems to have come from somewhere other than the text in the LRM. >Evaluating in the observed region is really very simple. When a case- or >if-variable changes in one of the RTL regions, an assertion event is >scheduled in the observed region. When the observed region events are >activated, we find out if there are any violations. If multiple changes >occur on a case- or if-variable within a time step, it behaves like >nonblocking assignments and the last stored event is evaluated, potentially >missing other error events in the same time step. No, this won't work. You can't just evaluate the "assertion" in the observed region. Execution might not have reached the if/case because of conditional code around it, and you can't just assume it did. If it didn't execute, there wasn't a failure. You also don't have access to the values of any temporary variables that were computed in the code around it. The only time you can evaluate the "assertion" is when the if/case actually executes. What you *can* do is delay producing the error until the observed region. If the most recent time the if/case executed did not have a violation, then you don't produce the error. But you have to rely on the if/case to do the evaluation itself and provide it to the process running in the observed region. As noted previously, if the same if/case is executed repeatedly in the same time slice for reasons other than glitching inputs in combinational blocks (e.g. for-loops and functions), this filtering may lose actual errors. There may be better alternatives. For example, the single-block FSM approach (that you dislike) does not seem to have this problem. It appears to work fine with the "immediate assertion" treatment. Since the combinational logic is in the clocked block, it won't get evaluated by the simulator until its result is about to be used. Any glitches will be gone. It will only get evaluated once in a time slice, at the clock edge. If there is a loop, each value computed by the loop will get checked, and no errors will get lost. This may not work for everything, but there may be other solutions. There may be other design styles that avoid this problem. Steven Sharp sharp@cadence.comReceived on Tue Apr 5 20:08:00 2005
This archive was generated by hypermail 2.1.8 : Tue Apr 05 2005 - 20:08:11 PDT