Should <resync_br> issue the address by format 1?

[zhangdujiao]

resync_br: resync count == max_resync and branch map not empty.
Should this condition issue the address by format 1 (with address), or only branch_map is reported by format 1 (no address)?

[IainCRobertson]

There is no need to send an address. The purpose of this packet is to send the branch status to the decoder before the sync-start which will follow. Iain From: zhangdujiao ***@***.***> Sent: 03 September 2024 12:34 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Should <resync_br> issue the address by format 1? (Issue #139) resync_br: resync count == max_resync and branch map not empty. Should this condition issue the address by format 1 (with address), or only branch_map is reported by format 1 (no address)? - Reply to this email directly, view it on GitHub<#139>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSX5TTVGRFGX3FFY4TTZUWND5AVCNFSM6AAAAABNR5ZCV2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDENRTHE4DCOA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[zhangdujiao]

There is no need to send an address.
<resync_br or er_n> are combined together, what about <er_n> condition? should the address be included in the format 0/1/2

[IainCRobertson]

Yes. Whenever there is an exception or interrupt, it is necessary to report the address of the final instruction retired beforehand. Iain From: zhangdujiao ***@***.***> Sent: 10 September 2024 03:30 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW ICS DDCP TST RD EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Should <resync_br> issue the address by format 1? (Issue #139) There is no need to send an address. <resync_br or er_n> are combined together, what about <er_n> condition? should the address be included in the format 0/1/2 - Reply to this email directly, view it on GitHub<#139 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXY2ARSC4MOY2LTV5TZVZKSDAVCNFSM6AAAAABNR5ZCV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZZGQ4DMOJYGM>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[zhangdujiao]

it is necessary to report the address of the final instruction retired beforehand
For the inst. block (er_n) as follow:
inst1
inst2
exception
Can the address before exception be calculated from: iaddr + 2*(iretire - 2^ilastsize)?
iretire only contain the half-word count of inst1 and inst2, exception is not included, right?
and ilastsize just represents the size of inst2, right?

[IainCRobertson]

Yes, you are correct: Iretire is the number of retired instruction half-words, so doesn't include the instruction which caused the exception. It is always necessary to report the address of the last instruction before the exception, as the decoder would otherwise have no idea where the exception occurred. Iain From: zhangdujiao ***@***.***> Sent: 12 September 2024 08:43 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW ICS DDCP TST RD EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Should <resync_br> issue the address by format 1? (Issue #139) it is necessary to report the address of the final instruction retired beforehand For the inst. block (er_n) as follow: inst1 inst2 exception Can the address before exception be calculated from: iaddr + 2*(iretire - 2^ilastsize)? iretire only contain the half-word count of inst1 and inst2, exception is not included, right? and ilastsize just represents the size of inst2, right? - Reply to this email directly, view it on GitHub<#139 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSRWK42AYTEOIVW7FN3ZWFAYHAVCNFSM6AAAAABNR5ZCV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBVGUYDEMRXGI>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[zhangdujiao]

thanks! problem solved

[zhangdujiao]

The purpose of this packet is to send the branch status to the decoder before the sync-start which will follow

I noticed that for most of the cases, current is "resync_cnt < resync_max" and next is "resync_cnt > resync_max" if the count mode is selected to half-word count of retired inst.
i.e. if resync_cnt > resync_max in next cycle, it should report branch information this cycle.

Should the condition "resync count == max_resync" in Figure9.1 be modified to "next_resync_cnt > max_resync"?

[IainCRobertson]

Dujiao, This is deliberate, but in hindsight not literally accurate for all resync modes. The point it is trying to convey is that the branch map needs to be output first, before the sync packet. There is really a small FSM required to manage the sync process: * State 1: count < max_resync * Stay in this state until count >= max_resync, then move to state 2 * State 2: send branch map * Move to state 3 * State 3: send sync * Reset counter and move to state 1 For packet-based resync, the counter only increments one at a time and the FSM states can be identified by * State 1: count < resync_max * State 2: count == resync_max * State 3: count > resync_max and this is what the diagram conveys - the count is the FSM. But this is not entirely accurate for the other modes. If the diagram were changed as you suggest then there would be nothing to ensure that the branch map was output before the sync packet, so this is not the right solution. A better change would be to describe the resync FSM in the text, and then refer to the states in the diagram. Leave the issue open and I'll take an action to do this. Iain From: Dujiao ***@***.***> Sent: 17 November 2024 02:28 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] Should <resync_br> issue the address by format 1? (Issue #139) The purpose of this packet is to send the branch status to the decoder before the sync-start which will follow I noticed that most of the cases, current is "resync_cnt < resync_max" and next is "resync_cnt > resync_max" if the count mode is selected to half-word count of retired inst. i.e. if resync_cnt > resync_max in next cycle, it should report branch information this cycle. Should the condition "resync count == max_resync" in Figure9.1 be modified to "next_resync_cnt > max_resync"? - Reply to this email directly, view it on GitHub<#139 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSUDE4Z4GF7EQMRJRFL2A75LJAVCNFSM6AAAAABNR5ZCV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQHA4TKNRTGI>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[IainCRobertson]

Dujiao, That works for packets and half-words, but not for cycles. The number of cycles between instruction retirements is unconstrained, so it's possible that when next_count is checked, it could be some way below max_resync, but there could then follow some number of idle cycles such that when the next instruction retires the count is > max_resync, and the test nearer the top of the flow diagram would produce a sync packet without having first issued the branch map. Iain From: Dujiao ***@***.***> Sent: 19 November 2024 03:23 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] Should <resync_br> issue the address by format 1? (Issue #139) If the diagram were changed as you suggest then there would be nothing to ensure that the branch map was output before the sync packet, so this is not the right solution. * State 1: count < resync_max * State 2: count == resync_max (next_count > resync_max) * State 3: count > resync_max Just modify the "count == resync_max" to "next_count > resync_max" seems satisfied every count mode. right? - Reply to this email directly, view it on GitHub<#139 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXXIG7J5YA5VNT4O6T2BKVH3AVCNFSM6AAAAABNR5ZCV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBUGYZDMMZSGA>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>