search

riscv-non-isa / riscv-trace-spec

RISC-V Processor Trace Specification
https://jira.riscv.org/browse/RVG-88
Creative Commons Attribution 4.0 International
152 stars 47 forks source link

Should each ingress port signal group match separated comparators and filter? #132

Open zhangdujiao opened 1 month ago

zhangdujiao commented 1 month ago

If we have two ingress port signal group. Now two ways can be applied: 1. group0 -> comparator0 -> filter0 group1 -> comparator1 -> filter1

2. group0 & group1 -> comparator0 -> filter0

which way is better?

IainCRobertson commented 1 month ago

Option 2. For example, suppose you want to trace if the instruction address is between A and B. You only need one comparator unit and one filter to do this. It shouldn't matter how the hart to encoder interface is set up - single instruction, single group, multiple single instruction lanes or multiple groups. The user shouldn't have to program the filtering differently depending on the architecture of the processor.

When using groups, the comparator will need to take into account the lower and upper address represented by each group. For example, address A may be in the middle of the set of instructions retired in that group in that cycle. When there are multiple groups (or single retirement lanes) the comparator will need to look at all of them in parallel. If any of the instructions retired in the cycle match the filtering criteria, the recommendation is to trace all the instructions retired in that cycle.

Iain

From: zhangdujiao @.> Sent: 01 August 2024 04:37 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] Should each ingress port signal group match separated comparators and filter? (Issue #132)

If we have two ingress port signal group. Now two ways can be applied: 1. group0 -> comparator0 -> filter0 group1 -> comparator1 -> filter1

1.

group0 & group1 -> comparator0 -> filter0

which way is better?

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

zhangdujiao commented 1 month ago

Very important example, I need to reconsider the design. For the comparator arithmetic, =, !=, <=, >=, etc... For example, when a instruction block is sent to the comparator, we can obtain the 1st address and last address of this block. If the trTeCompPFunction = 0 ("="), the result is true when: (cfg_value >= 1st address) & (cfg_value <= last address) For "!=": (cfg_value < 1st address) | (cfg_value > last address) For "<" last address < cfg_value For ">" 1st address > cfg_value ... Is this reasonable?

IainCRobertson commented 1 month ago

Yes, that's exactly right.

Iain

From: zhangdujiao @.> Sent: 13 August 2024 08:48 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 each ingress port signal group match separated comparators and filter? (Issue #132)

Very important example, I need to reconsider the design. For the comparator arithmetic, =, !=, <=, >=, etc... For example, when a instruction block is sent to the comparator, we can obtain the 1st address and last address of this block. If the trTeCompPFunction = 0 ("="), the result is true when: (cfg_value >= 1st address) & (cfg_value <= last address) For "!=": (cfg_value < 1st address) | (cfg_value > last address) For "<" last address < cfg_value For ">" 1st address > cfg_value ... Is this reasonable?

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

zhangdujiao commented 5 days ago

Hi Iain, a new problem, we can get the last address of the block from : iaddr+2(iretrie-2^ilastsize), that should be correct. However, when we use the address range (1st_addr and last_addr) to match the cfg_value in comparator, the last instruction could be 16-bits or 32-bits wide, and we only count the 1st byte address of the last inst. What about the address of last 1 or 3 bytes? If it should be counted in the address range, the last_address should be change to iaddr+2*iretrie -1. So, should the address of last byte of the last inst. be counted within the address range? many thanks!

zhangdujiao commented 5 days ago

If the last address of inst. should be included in te_inst, like at the condition. Ss this following formula correct?
last_addr = iaddr+2(iretrie-2^ilastsize)

IainCRobertson commented 1 day ago

You should base the comparison on the address of the 1st byte of the instruction.

Iain

From: zhangdujiao @.> Sent: 07 September 2024 04:06 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 each ingress port signal group match separated comparators and filter? (Issue #132)

Hi Iain, a new problem, we can get the last address of the block from : iaddr+2(iretrie-2^ilastsize), that should be correct. However, when we use the address range (1st_addr and last_addr) to match the cfg_value in comparator, the last instruction could be 16-bits or 32-bits wide, and we only count the 1st byte address of the last inst. What about the address of last 1 or 3 bytes? If it should be counted in the address range, the last_address should be change to iaddr+2*iretrie -1. So, should the address of last byte of the last inst. be counted within the address range? many thanks!

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

IainCRobertson commented 1 day ago

Yes, assuming ^ represents exponentiation. In other words 2^0 is 1 and 2^1 is 2.

Iain

From: zhangdujiao @.> Sent: 07 September 2024 04:13 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 each ingress port signal group match separated comparators and filter? (Issue #132)

If the last address of inst. should be included in te_inst, like at the condition. Ss this following formula correct? last_addr = iaddr+2(iretrie-2^ilastsize)

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

zhangdujiao commented 13 hours ago

Thanks Iain, If the ingress port signal is: itype=1/2, iretire=0, which means exc_only. What does the iaddr mean? When itype=1, does iaddr mean the address of the inst. which occur an exception? When itype=2, is iaddr meaningless?

Under this condition, if the comparator is configured by address match, how to match if the iaddr is meaningless?

IainCRobertson commented 4 hours ago

Yes, exactly. For interrupts, the address filtering should be ignored when iretire=0.

Iain

From: zhangdujiao @.> Sent: 12 September 2024 08:39 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 each ingress port signal group match separated comparators and filter? (Issue #132)

Thanks Iain, If the ingress port signal is: itype=1/2, iretire=0, which means exc_only. What does the iaddr mean? When itype=1, does iaddr mean the address of the inst. which occur an exception? When itype=2, is iaddr meaningless?

Under this condition, if the comparator is configured by address match, how to match if the iaddr is meaningless?

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