Updates 2.0.4 issue 154 #165
Conversation
fragmentCodeAndTransport.adoc
Outdated
| The packet format is given in | ||
| <<fig:packet-format>>. So this means the packet | ||
| will be packed as follows: | ||
| The packet is encapsulated according to the https://drive.google.com/file/d/1R-_koXIpdb9_qW6jpz74TSnNXOfJGhfn/view?usp=drive_link[Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V Specification], with the following attributes: |
There was a problem hiding this comment.
I think that this should link to https://github.com/riscv-non-isa/e-trace-encap/releases/download/v1.0/e-trace-encap.pdf instead. Someone at the Summit said that RVI is migrating away from Google because google.com is blocked in some countries.
There are additional places below that would also need to change.
There was a problem hiding this comment.
@rpsene @wmat can I get your input here? I used the link from the Tech specs page (https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications), but what is the preferred way to refer to other specs? The problem with using the link Paul suggested is that this will be wrong if/when we do an update for the E-Trace Encap spec. I want something which always points to the latest approved/published version.
There was a problem hiding this comment.
I don't think that a drive.google.com link will always point to the latest, either. It points to a specific file, similar to pointing to a file by inode rather than pointing to a file by name.
https://github.com/riscv-non-isa/e-trace-encap/releases/latest/ will always point to the latest release, though you have to do an additional click to get the PDF.
There was a problem hiding this comment.
@wmat, understood, and that’s why I picked the google drive link – I want the doc reference to always point to the latest published. But with the move away from google docs, presumably the link for latest published is going to change to something else. Do we know what this is yet? Or are we going to have to scour all the specs for references to google links and replace them after that decision is made?
There was a problem hiding this comment.
If we go with the Google link then the downsides are:
- People in certain geographies (which constitute a significant percentage of RISC-V users) cannot follow the link today.
- If/when v1.0.1 of the encapsulation spec is released then the link will be obsolete (since it points directly to the v1.0 file).
- It will need to be updated when we migrate from Google (unless the Google link continues to work).
If we go with my original link then the downsides are:
- If/when v1.0.1 of the encapsulation spec is released then the link will be obsolete (since it points directly to the v1.0 file).
- We might want to update the link to point to something else when we migrate from Google (though I don't think that this would be mandatory until v1.0.1 comes out).
If we go with the "latest" link (in my previous comment) then the downsides are:
- People have to do an additional click to get the actual spec.
Or maybe we just don't have a link at all. People would just have to go figure it out.
There was a problem hiding this comment.
Perhaps a link to "latest" with instructions in the GitHub README about what to do next?
|
The top of tree link is always the most current version, however it may not
be the last “published” version. To get that version you have the option of
finding that release in the list of releases on GitHub or linking to the
last published PDF document mentioned on Google Drive.
…On Fri, Oct 25, 2024 at 6:24 PM Paul Donahue ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In fragmentCodeAndTransport.adoc
<#165 (comment)>
:
> @@ -98,24 +98,29 @@ line 56. The least significant byte is output first, this means 32 is
byte 0, 04 is byte 1 and and the final value 02 is byte 4.
==== Siemens transport
-
-The packet format is given in
-<<fig:packet-format>>. So this means the packet
-will be packed as follows:
+The packet is encapsulated according to the https://drive.google.com/file/d/1R-_koXIpdb9_qW6jpz74TSnNXOfJGhfn/view?usp=drive_link[Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V Specification], with the following attributes:
I don't think that a drive.google.com link will always point to the
latest, either. It points to a specific file, similar to pointing to a file
by inode rather than pointing to a file by name.
https://github.com/riscv-non-isa/e-trace-encap/releases/latest/ will
always point to the latest release, though you have to do an additional
click to get the PDF.
—
Reply to this email directly, view it on GitHub
<#165 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN6ZEX5FH3BWGK3U4OORLZ5LAIVAVCNFSM6AAAAABQP7X2MOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGOJWGU4TCNRSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks @pdonahue-ventana @wmat for your input. I have updated to point to https://github.com/riscv-non-isa/e-trace-encap/releases/latest/. I don't think a README update is needed - there are only 3 links on the latest page, one of which is clearly the spec PDF @ved-rivos this is now with you for approval |
| * SrcID - N bits. As an example use 6 bits and the value of 1. | ||
| * This example has no timestamp | ||
| * A 2-bit type field with ’10’ meaning instruction trace | ||
| * trace_payload - [32 04 00 00 02] |
There was a problem hiding this comment.
Prefix with 0x to match the following text.
|
|
||
| ==== ATB transport | ||
|
|
||
| Assuming at 32 bit ATB transport results in the following ATB transfers | ||
| The packet is encapsulated according to the https://github.com/riscv-non-isa/e-trace-encap/releases/latest/[Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V Specification], with the following attributes: | ||
|
|
There was a problem hiding this comment.
Clarify that the encapsulated packet is held in ATDATA
|
@ved-rivos requested updates made |
This replaces the informative encapsulation examples with text that references E-Trace-Encap.