Interaction with trace

[joxie]

1. Reuse the existing interface:

Use existing trace-on/trace-off triggers
Potential race condition when trigger is set to those action.

2. Use halted signal

The signal has to be in-band to be synchronized with trace output transaction.
With a new xtrcen signal in the interface
Same behavior as halted signal. Avoid confusion with ”halt” in Debug spec

[joxie]

Conclusion is to use new signal (or a vector) rather than halted, @AoteJin to work on the details

[AoteJin]

Revisit the e-trace and debug spec, trace-on/trace-off trigger are defined as sideband signal to trace encoder and their priority are UNDEFINED (debug spec says it should be defined by trace spec, while e-trace spec doesn't define it, hmmm... ). Thus, it cannot be a candidate for trace control.

Based on discussion on TG meeting, adding another bit alongside halted signal to bundle a vector is friendly to future extension.

[new_bit, halted]	Tracing?	Disable reason
00	Yes	n/a
01	No	entering Debug Mode
10	No	due to security rules
11	No	reserved for future

It should be general to accommodate both e-trace and n-trace.

[AoteJin]

@bcstrongx @sifiverobert @IainCRobertson could you help review the above solution. If the idea is acceptable, the external debug security spec will follow this direction.

[bcstrongx]

This looks good to me.

[mipsrobert]

Looks good to me as well.

[IainCRobertson]

Apologies for the delay - I've been on vacation. This looks good to me too. We will need an issue opening against the E-Trace spec. At some point the interface will be pulled out of the E-trace spec into a separate standalone doc, but either way this change will lead to a minor-version change (if still within E-Trace it would be 2.1.0).

You should also add guidance about interoperability with trace encoders compatible with the current spec (OR these 2 bits together and connect to the TE's 'halted' input).

Regarding your comment about trace-on/off priority, can you clarify what you mean exactly? The E-Trace spec is clear that tracing starts from the cycle in which trace-on is asserted, and stops after the cycle in which trace-off is asserted. By implication, if both are asserted together, only instructions retired in that cycle will be traced. I don't see an ambiguity about priority here. Or is your concern something else?

[AoteJin]

Apologies for the delay - I've been on vacation. This looks good to me too. We will need an issue opening against the E-Trace spec. At some point the interface will be pulled out of the E-trace spec into a separate standalone doc, but either way this change will lead to a minor-version change (if still within E-Trace it would be 2.1.0).

Sure! I will open an issue for e-trace regarding the new signal.

You should also add guidance about interoperability with trace encoders compatible with the current spec (OR these 2 bits together and connect to the TE's 'halted' input).

Thanks for reminding! It is a really good point.

Regarding your comment about trace-on/off priority, can you clarify what you mean exactly? The E-Trace spec is clear that tracing starts from the cycle in which trace-on is asserted, and stops after the cycle in which trace-off is asserted. By implication, if both are asserted together, only instructions retired in that cycle will be traced. I don't see an ambiguity about priority here. Or is your concern something else?

Actually, I mean the following case might be hazardous with trace-on/trace-off signals:

1. Triggers set to trace-on at PC 0x8 while trace-off at PC 0x4
2. Triggers set to trace-on at PC 0x8 while xtrcen enforce trace-off at PC 0x4 (assuming privilege change after 0x4)

[IainCRobertson]

Case 1: assuming code is executing linearly and is active initially, trace will stop after 0x4, and then start at 0x8. If 0x4 is a 16-bit instruction then the instruction at 0x6 will not be traced (though I think you're assuming 32-bit instructions and 0x8 is the instruction after 0x4).

Case 2: xtrcen if a level, not a pulse (same as halted signal). So if was low after 0x4, nothing will be traced again until it goes high. However, all signals on the interface are ignored when halted is high (or xtrcen is low), and this includes the triggers. So when xtrcen eventually goes high again, tracing will not start until there is a trace-on trigger. In other words trace on/off triggers are only effective if the code they are associated with is permitted to be traced. This could definitely be clarified.

[AoteJin]

Yes, I am assuming 32-bits instruction only.
I think the previous discussion to leverage trace-on/trace-off for security control is to avoid the xtrcen or halted signal being used. And if xtrcen and halted signal is not used for security control, the trace-on/trace-off signal are not blocked. Then case 2 is basically a variant of case 1 (the only difference is trace-off is driven by xtrcen instead of trigger). The case 1, as described above, effectively appears as there is no trace-on/trace-off happened.
Above all, my concern is that the trigger configuration might potentially cancel the operation when xtrcen stop the trace via trace-off.

[IainCRobertson]

Okay, so in that case, tracing should continue. The trace-off at 0x4 says "this is the last instruction traced", but the trace-on at 0x8 says "this is the 1st instruction traced". The end result is that the trace enable never actually goes low.

However, I accept that this is not stated explicitly and could be clarified.

[AoteJin]

The external debug security spec use the signal vector to inform the trace module that it should stop output per commit #19.
It uses the name sec_check for new signal, will align to the trace spec when it is updated.