Clarification on whether `control_i.else` affects software fault injection

[MarkHillCodasip]

If control_i.else (error-logging-and-signaling-enable) is clear when the control_i.eid (error-injection-delay) count reaches 0 does this inhibit the setting of control_i.v to 1?

[gfavor]

The intent of error injection is that software can set up things up however it likes (i.e. for whatever it is trying to test), then set up an injection delay and wait. Once the delay elapses, normal behavior - based on what software had configured and set up - ensues. If software configured the else bit as zero, then the normal resulting behavior is what software will get. For better or worse, that was its choice.

[MarkHillCodasip]

Thanks Greg, so to summarise:

If control_i.else (error-logging-and-signaling-enable) is clear when the control_i.eid (error-injection-delay) count reaches 0 it inhibits the setting of control_i.v to 1.

[gfavor]

Thanks Greg, so to summarise: If control_i.else (error-logging-and-signaling-enable) is clear when the control_i.eid (error-injection-delay) count reaches 0 it inhibits the setting of control_i.v to 1.

The specs says "When else is 0, any signaling associated with prior logged errors remains unaffected, the hardware unit does not log and signal new errors in the error record." So the error record contents that software pre-configured before activating the error injection delay remain unchanged in any case (since no actual new error was detected). And no error signaling occurs. But, to your more specific question, the specs says "When eid reaches a count of 0, the status register is made valid by setting the status_i.v bit to 1." So that is what will happen. Nothing in the spec says or suggests otherwise, i.e. a literal reading of this statement should be the correct reading and should not conflict with anything else in the spec (which it doesn't). This may be an unusual scenario for test software to set up and exercise, but hardware behavior should follow what the spec literally says. (The goal of the spec is to not require the reader to infer intended semantics that aren't more explicitly stated. If there is something ambiguous in this regard, then please raise that for explicit clarification in the spec.) Greg