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

"iaddress_width_p - iaddress_lsb_p": the width of Delta address and Full address #110

Closed zhangdujiao closed 3 months ago

zhangdujiao commented 3 months ago

From Chapter7, the width of address in Packet is "iaddress_width_p - iaddress_lsb_p", for both delta address and full address, the widths are totally the same. So, I don't see the advantage of the delta address. Did I miss something?

The "iaddress_width_p" is the width of instruction address. While the "iaddress_lsb_p" is hard to understand. From the definition, iaddress_lsb_p: LSB of instruction address bus to trace. 1 is compressed instructions are supported, 2 otherwise. iaddress_lsb_p can only be 1 or 2?
1: compressed instructions are supported——means the width of address can be compressed? 2: otherwise

IainCRobertson commented 3 months ago

See inline...

Iain

From: zhangdujiao @.> Sent: 21 May 2024 08:56 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] "iaddress_width_p - iaddress_lsb_p": the width of Delta address and Full address (Issue #110)

From Chapter7, the width of address in Packet is "iaddress_width_p - iaddress_lsb_p", for both delta address and full address, the widths are totally the same. So, I don't see the advantage of the delta address. Did I miss something?

[Iain] Yes. The address field is usually the last field in the te_inst packets, and when it is not the last, the fields which follow it are Manchester encoded so that most of the time they take the same value as the MSB of the address field. This means that the upper bits of the packet can be compressed away for transmission. Differential addresses generally have most upper bits the same, meaning that the effective packet size after MSB-compression is much less for differential addresses than full addresses. The decoder can reconstruct the uncompressed packet simply by sign extending from the compressed packet it receives.

The "iaddress_width_p" is the width of instruction address. While the "iaddress_lsb_p" is hard to understand. From the definition, iaddress_lsb_p: LSB of instruction address bus to trace. 1 is compressed instructions are supported, 2 otherwise. iaddress_lsb_p can only be 1 or 2? 1: compressed instructions are supported--means the width of address can be compressed? 2: otherwise

[Iain] Yes. Instructions are always either 16 or 32 bits in length, and addresses are always 16-bit aligned, or 32-bit aligned if compressed instructions are not supported. This means that the LSB of an instruction address is always 0, and if only 32-bit instructions are supported, the 2LSBs of the address are 0. There is no point sending these LSBs in the trace packet because the decoder knowns they are 0 and it's just a waste of bandwidth. Iaddress_lsb_p indicates the least significant bit of the address which is not always 0. This is also the number of LSBs of the address that are not included in the trace packets, and the number of bits of left-shift required to convert the address field of the trace packet into the original address.

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

zhangdujiao commented 3 months ago

The address field is usually the last field in the te_inst packets, and when it is not the last, the fields which follow it are Manchester encoded so that most of the time they take the same value as the MSB of the address field. Thank, I get the point of this field arrange. While, there is still a question on payload compression. See the example from Chapter13.1, "56: format=2, address=8000010c, irreport=0, notify=0, updiscon=0, Reason[exc_only] Payload[32 04 00 00 02]"

  1. The width of address is 32bit, not 31 or 30, right shifted 1 or 2.
  2. I didn't see the compression here. Supposing the delta form of this address is 0x12, and if we need compress this payload, should I 1) compress the MSB of delta address (which is 0), irreport, notify and updiscon by MSB-compression first, then packed the compressed field together. Or, 2) I need to packet these fields together and then compress the packed payload by MSB-compression. Since the first byte of payload is always format and subformat, there is no space to compress, so the first way is resonable?
IainCRobertson commented 3 months ago

Sorry, this example is at best confusing. It appears that for this example the packet payloads include full rather than differential addresses (in other words, the 'full_address' option encoder option has been enabled). This option is intended to aid with debug when developing a software decoder and is not intended for normal use as it has very poor compression. Furthermore it appears that the payload has been constructed with iaddress_lsb_p = 0, so contains the exact full address.

For a more typical use case where differential addresses are used and iaddress-lsb_p is 1, the packet payload would be as follows: The previous format 1 te_inst (line 53) was reporting address 0x80000104, and this packet is for 0x8000010c, so the differential address would be 0x8. With iaddress_lsb_p = 1, the diff address field is 0x00000004. The packet payload in binary with the LSB on the right and MSB on the left with all the identical MSBs compressed away is therefore 010010, which as a network order byte stream is represented as [12]. Packet payload length is 1 byte. Compression is always performed on the entire payload after concatenating all the fields together.

Iain

From: zhangdujiao @.> Sent: 22 May 2024 08:28 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] "iaddress_width_p - iaddress_lsb_p": the width of Delta address and Full address (Issue #110)

The address field is usually the last field in the te_inst packets, and when it is not the last, the fields which follow it are Manchester encoded so that most of the time they take the same value as the MSB of the address field. Thank, I get the point of this field arrange. While, there is still a question on payload compression. See the example from Chapter13.1, "56: format=2, address=8000010c, irreport=0, notify=0, updiscon=0, Reason[exc_only] Payload[32 04 00 00 02]"

  1. The width of address is 32bit, not 31 or 30, right shifted 1 or 2.

  2. I didn't see the compression here. Supposing the delta form of this address is 0x12, and if we need compress this payload, should I

  3. compress the MSB of delta address (which is 0), irreport, notify and updiscon by MSB-compression first, then packed the compressed field together. Or,

  4. I need to packet these fields together and then compress the packed payload by MSB-compression. Since the first byte of payload is always format and subformat, there is no space to compress, so the first way is resonable?

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

zhangdujiao commented 3 months ago

Compression is always performed on the entire payload after concatenating all the fields together

Excellent example, problem solved, thanks!