Branch_map full when sync packet issues

[zhangdujiao]

When sync packet (fmt3) issues, if the branch_map also get full (supposing branch_predition mode is not enabled) at the same time. Then additional fmt1-noaddr packet will be reported at the same time, right?

[IainCRobertson]

Dujiao, Yes, any time there is a format 3 sync-start or sync-trap scheduled for the next instruction, a format 0/1/2 must be issued for the current instruction if there are any unreported branches.

Iain

From: Dujiao @.> Sent: 19 November 2024 07:05 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] Branch_map full when sync packet issues (Issue #174)

When sync packet (fmt3) issues, if the branch_map also get full (supposing branch_predition mode is not enabled) at the same time. Then additional fmt1-noaddr packet will be reported at the same time, right?

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/174, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXCBPQCCJFGTEA2F4L2BLPH5AVCNFSM6AAAAABSBLVRR2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3TCMBSGQYDOOI. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[zhangdujiao]

Yes, I got this. Thanks Iain. The example here is: itype=4, and satisfy the and <branches==31>, then two packets should be issued at this cycle: 1) sync-trap to report trap handler address. 2) fmt1 to report branch_map. Is it correct?

[IainCRobertson]

Dujiao, No, that's not right - the branch history relates to branches that occurred before the exception, and so has to be output before the sync-trap, not after. If itype =4 and exception_previous is true, then this branch will be dealt with via the 'branch' bit in the sync-trap packet. The previous branch history should have been reported before the sync trap.

Firstly, consider the behaviour if the hart retires one instruction per cycle. This is illustrated in Fig2. What will happen is this:

1. Some instruction retires, branch map is > 0
2. There is an exception
3. The 1st instruction in the trap hander retires. This is a branch

In the flow diagram, for the instruction at step 1, the green diamond will resolve to true as there is an exception next, and the branch map will be output. The exception itself will not produce a packet, then for the instruction in step 3, the 'exception previous' orange diamond will resolve true, exc_only will be true and a sync-trap will be generated.

If the instructions are retired in blocks, step 1 and 2 may be separate blocks:

1. A block of instructions retires (iretires = N), branch map > 0, itype != 1,2
2. There is an exception

Or if itype for that block was 0, they could be combined into a single block, with iretires = N and itype = 1

But regardless, the outcome must be the same - the decoder sees exactly the same packet sequence as if the hart was retiring the instructions one at a time. The flow diagram only works instruction by instruction, not block by block - you will need to adapt to achieve the equivalent behaviour, as effectively the encoder is processing multiple instructions concurrently. In this case, the last instruction in the block will trigger the format 0/1/2 because there is an exception next, even if the exception is reported as part of the same block.

Iain

From: Dujiao @.> Sent: 19 November 2024 13:40 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW EDA DDCP TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] Branch_map full when sync packet issues (Issue #174)

Yes, I got this. Thanks Iain. The example here is: itype=4, and satisfy the and <branches==31>, then two packets should be issued at this cycle:

1. sync-trap to report trap handler address.
2. fmt1 to report branch_map. Is it correct?

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/174#issuecomment-2485750542, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSVKSHWX7TMU5ZDSXX32BM5RRAVCNFSM6AAAAABSBLVRR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBVG42TANJUGI. You are receiving this because you commented.Message ID: @.**@.>>

[zhangdujiao]

Oops, I missed the 'next' condition check before the exception and the "resync_cnt == max" before sync-start packet. Thank you so much, Iain!