TMS320F28388S: TMS320F28388S Rev A — Guaranteed CPU-cycle bounds for Fatal NMI WCET analysis

wang george

Prodigy 10 points

Part Number: TMS320F28388S

Hello TI Support,

We are performing a formal CPU-cycle worst-case execution-time analysis for a Fatal NMI handler on:

Device: TMS320F28388S
Silicon revision: Rev A
Core: CPU1 C28x
NMI watchdog period: NMIWDPRD = 0xFFFF

The analysis requires guaranteed maximum timing bounds suitable for formal WCET analysis.

We are not looking for typical values, measured latency, or GPIO pad propagation timing.

For each item below, please identify the applicable TI document, section, table, erratum, or other authoritative guaranteed source, together with any required operating conditions such as SYSCLK, peripheral clock, power state, arbitration state, or debug/emulation restrictions.

1. CPU1 NMI register read stall / ready-extension bound

The Fatal NMI handler performs the following CPU1 C28x reads:

MOV *-SP[7], *(0:0x7061)   ; CPU1 NMIFLG
MOV *-SP[8], *(0:0x7066)   ; CPU1 NMISHDFLG

For these reads, what is the guaranteed maximum additional CPU stall or ready-extension latency, beyond the documented C28x instruction base timing, under all documented valid operating conditions for TMS320F28388S Rev A?

If the latency depends on a peripheral bus, bridge, arbitration condition, or ready-extension mechanism, please specify:

the relevant condition;
the guaranteed worst-case additional latency;
the unit of that bound;
whether any additional pipeline stall must be included separately.

If no published guaranteed maximum exists, please state that explicitly.

2. GPIO CLEAR write CPU-visible completion / stall bound

The Fatal NMI handler performs the following CPU1 C28x 32-bit writes:

VMOV32 *(0:0x7F04), ACC
VMOV32 *(0:0x7F24), ACC
VMOV32 *(0:0x7F2C), ACC

These accesses target GPIO CLEAR registers.

For each write, what is the guaranteed maximum CPU-visible instruction completion / stall latency, beyond the documented C28x instruction base timing, under all documented valid operating conditions for TMS320F28388S Rev A?

Please also clarify whether these GPIO writes are posted or non-posted.

If they are posted, please distinguish the following events:

the point at which the issuing C28x instruction is considered complete;
the point at which the write is accepted by the GPIO peripheral;
any later GPIO output/pad effect.

For our current WCET endpoint, item 3 is outside the CPU-cycle interval of interest. We need the guaranteed CPU-visible timing associated with items 1 and, where relevant to instruction completion, item 2.

Please provide a guaranteed maximum suitable for formal WCET analysis, or state explicitly if no such guaranteed bound is published.

3. NMI watchdog counter headroom at Fatal-handler entry

According to the F2838x documentation, assertion of an enabled NMI FAIL flag starts the NMI watchdog counter NMIWDCNT, which is clocked from SYSCLKOUT.

Our formal WCET interval begins at the first executed instruction of the Fatal NMI handler:

CPU1 address 0x1A0AD
M2Safety_fatalNmiHandler
instruction: ASP

The interval ends before the terminal self-loop, after completion of the final Fatal-state store.

NMI acceptance latency and hardware automatic-context-save execution occur before our formal WCET start point, but they consume watchdog headroom before execution reaches 0x1A0AD.

For TMS320F28388S Rev A with:

NMIWDPRD = 0xFFFF

what is the guaranteed maximum elapsed SYSCLKOUT-cycle count from the enabled NMI FAIL-flag assertion that starts NMIWDCNT until CPU1 begins execution at address 0x1A0AD?

Alternatively, if TI specifies this behavior directly in watchdog-counter terms:

What is the guaranteed maximum possible value of NMIWDCNT when CPU1 begins executing address 0x1A0AD?

Please provide the result as a guaranteed upper bound suitable for formal WCET analysis.

Please also clarify the relationship between:

one NMIWDCNT increment;
one SYSCLKOUT cycle;
C28x CPU execution cycles

for this device/configuration.

If conversion from watchdog counter ticks to C28x execution cycles requires any additional assumption, please identify that assumption explicitly.

In addition, while NMIWDCNT is already running, can assertion of another enabled NMI FAIL flag:

reset the counter;
restart the counter;
reload the counter;
delay its progression;
alter its count value;
or otherwise change the watchdog timeout timing?

If so, please describe the guaranteed behavior.

Please identify all conditions qualifying the guarantee, including as applicable:

device revision;
SYSCLK / SYSCLKOUT configuration;
interrupt recognition conditions;
NMI source;
power/clock state;
debug/emulation state.

Typical latency, measured latency, or nominal interrupt-response values are not sufficient for this analysis.

Purpose of the request

The formal property we need to establish is:

For every admitted Fatal-NMI execution beginning at 0x1A0AD,
the handler reaches its defined WCET endpoint before any
NMI-watchdog reset, and within <= 4096 C28x CPU cycles.

The entry-headroom precondition is defined independently and cannot be inferred retrospectively from successful execution.

Therefore, we require guaranteed upper bounds rather than empirical or typical timing values.

Backgroud:

We have already closed CPU1 DMA, CLA, GS13/GS14/LS5 contention and the core instruction/pipeline/branch/call timing model. The remaining blockers are limited to the three hardware timing authorities requested above.

Thank you.

17 天前