riscv-debug-spec
riscv-debug-spec copied to clipboard
riscv
What does AAM stand for?
Hello,
in general, I am missing a glossar in the document. At the moment, I waonde what "AAM" stands for. Maybe "abstract access memory"?
I don't see AAM used as a standalone term. Should it be defined if it's not used directly? We don't define other acronyms that are used as part of the names of registers or fields (AAR, HA, HG, SB, CS).
Well, SB happens in the chapter with System Bus, HA on the context of Hart Array, I do not find HG in the 2019 Mar 22 doc and AAR and AAM seem related. CS is probably Abstract Control and Status.
I feel a glossar would help for any of the acronyms.
It would be nice to have a glossary in the document, but it's not essential. If somebody has the time to put one together I'd be happy to review it.
Here is a list I generated.
--- Bruce
On Thu, Aug 26, 2021 at 12:34 PM Tim Newsome @.***> wrote:
It would be nice to have a glossary in the document, but it's not essential. If somebody has the time to put one together I'd be happy to review it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-debug-spec/issues/666#issuecomment-906686722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJOFJAH4NBDJXNQ66NOYVWTT62JLXANCNFSM5CL3ITQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Acronyms for RISC-V Debug Specification
AAM Abstract Access Memory - 'aam' is prefix to named fields of the Access Memory Command (cmdtype=2) AMO Atomic Memory Operation BIST Built-In Self Test BYPASS JTAG instruction that selects a single bit data register, called BYPASS CSR Control Status Register DM Debug Module DMI Debug Module Interface DR Data Register DTM Debug Transport Module DXLEN Widest supported XLEN of a hart GPR General Purpose Register Hart Hardware thread IDCODE 32-bit Identification CODE, and a JTAG instruction that returns the IDCODE value IR Instruction Register JTAG Joint Test Action Group MIE Machine Interrupt Enable register; also a bit in mstatus MIPI Mobile Industry Processor Interface - MIPI Alliance refers to organization that defines JTAG and trace probe connector and pin-out standards MPRV Modify PRiVilege - bit in mstatus NAPOT Naturally Aligned Powers-Of-Two NMI Non-Maskable Interrupt OpenOCD Open On-Chip Debugger PC Program Counter RV32 RISC-V core with XLEN of 32 RV64 RISC-V core with XLEN of 64 R/W1C Read/Write Ones to Clear SBA System Bus Access TAP Test Access Port WARL Write Any, Read Legal WARZ Write Any, Read Zero W1 Write-only; only writing 1 has an effect XLEN Width of the core's integer register file
I will assume that you're not proposing to remove the definitions of component, hardware platform, physical address, TM, virtual address, and xepc which are not in your list. It appears that you want to define AAM, BIST, MIE, MIPI, MPRV, OpenOCD, PC, RV32, RV64, R/W1C, WARL, WARZ, W1, XLEN.
I don't mind adding AAM, nor do I feel strongly that this is necessary.
I don't think that BIST should be in the glossary since it's only used once and it's defined in the place it's used: "built-in self test (BIST)"
The proposed definition of MIE is not accurate. MIE is not a register, it's the bit in mstatus. mie is a register. Do these two things need to be defined? The one place that refers to MIE says that it's in mstatus. The first reference to mie in section 5.5.14 says that it's described in the privileged spec and there are no references to mie outside of 5.5.14. But there's apparently confusion between MIE and mie so maybe they do both need to be defined.
I agree that MIPI should be defined.
MPRV should also be defined. It's sometimes called "MPRV in mstatus" but that's not consistent so there's not always context.
OpenOCD is only used once so it would be appropriate to provide any additional explanation in that sentence. Later in that same sentence it refers to Olimex which seems just as likely to be unknown to a reader but which I don't think either word needs to be in the glossary.
I'm leaning against defining PC, RV32, RV64, and XLEN. They are all fundamental RISC-V terms from the base unprivileged architecture and I think we have to assume some level of familiarity with that. We could go down the path of defining M-mode and interrupt and a thousand other things.
R/W1C, WARL, WARZ, W1 are all defined in table 1.2. It seems like the table should be removed if these are added to the glossary. I would lean toward keeping the table and not adding all of those terms to the glossary because putting "R" in the glossary seems strange (even though it is only ever used in the context of read-only CSRs).
These are all, of course, just my opinions and I welcome counter-arguments.
I just realized that the Debug spec has a Terminology, section 1.1 which has some of my list already. Perhaps just adding appropriate ones to it makes sense.
BTW, MIPI provides excellent documentation and in most (if not all) of their documents, they have a "Terminology" section with subsections "Definitions", "Abbreviations" and "Acronyms". Some of these include links to the next section "References" which includes descriptive links to other MIPI documents.
--- Bruce
On Fri, Aug 27, 2021 at 5:02 PM Paul Donahue @.***> wrote:
I will assume that you're not proposing to remove the definitions of component, hardware platform, physical address, TM, virtual address, and xepc which are not in your list. It appears that you want to define AAM, BIST, MIE, MIPI, MPRV, OpenOCD, PC, RV32, RV64, R/W1C, WARL, WARZ, W1, XLEN.
I don't mind adding AAM, nor do I feel strongly that this is necessary.
I don't think that BIST should be in the glossary since it's only used once and it's defined in the place it's used: "built-in self test (BIST)"
The proposed definition of MIE is not accurate. MIE is not a register, it's the bit in mstatus. mie is a register. Do these two things need to be defined? The one place that refers to MIE says that it's in mstatus. The first reference to mie in section 5.5.14 says that it's described in the privileged spec and there are no references to mie outside of 5.5.14. But there's apparently confusion between MIE and mie so maybe they do both need to be defined.
I agree that MIPI should be defined.
MPRV should also be defined. It's sometimes called "MPRV in mstatus" but that's not consistent so there's not always context.
OpenOCD is only used once so it would be appropriate to provide any additional explanation in that sentence. Later in that same sentence it refers to Olimex which seems just as likely to be unknown to a reader but which I don't think either word needs to be in the glossary.
I'm leaning against defining PC, RV32, RV64, and XLEN. They are all fundamental RISC-V terms from the base unprivileged architecture and I think we have to assume some level of familiarity with that. We could go down the path of defining M-mode and interrupt and a thousand other things.
R/W1C, WARL, WARZ, W1 are all defined in table 1.2. It seems like the table should be removed if these are added to the glossary. I would lean toward keeping the table and not adding all of those terms to the glossary because putting "R" in the glossary seems strange (even though it is only ever used in the context of read-only CSRs).
These are all, of course, just my opinions and I welcome counter-arguments.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-debug-spec/issues/666#issuecomment-907531364, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJOFJAFZLSFA3BFVBJU7PGTT7ARRDANCNFSM5CL3ITQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I think that a references section sounds great. I just looked and we actually already have that in the context section that's immediately after the terminology section (but I hardly ever look at this introductory material so I had forgotten that). We could possibly rename these sections and maybe rather than just saying that the debug spec "is written to work with" the other specs, we could say that it works with and "assumes familiarity with" those specs.
I'm OK splitting terminology into definitions and abbreviations, though it's not a very long section so I don't know if that would just be adding overhead.
On Fri, Aug 27, 2021 at 5:51 PM Paul Donahue @.***> wrote:
I think that a references section sounds great. I just looked and we actually already have that in the context section that's immediately after the terminology section (but I hardly ever look at this introductory material so I had forgotten that). We could possibly rename these sections and maybe rather than just saying that the debug spec "is written to work with" the other specs, we could say that it works with and "assumes familiarity with" those specs.
I'm OK splitting terminology into definitions and abbreviations, though it's not a very long section so I don't know if that would just be adding overhead.
I agree - one section for both is cleaner.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-debug-spec/issues/666#issuecomment-907540596, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJOFJAGMQLCDNMDJ36EQGV3T7AXIFANCNFSM5CL3ITQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
The terminology section has been enhanced and expanded over the last 18 months. If there are additional terms that might help, please create a PR.