tech-aia@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Topics Expanded

Between

and

Re: Slides from today's AIA meeting (12-08-2021)

Vedvyas Shanbhogue wrote: No, neither of those things. - John Hauser

By John Hauser · #138 ·

Re: Slides from today's AIA meeting (12-08-2021)

Hi All - Please help with this question on slide 6. Is the intent to define a new MSI data format to cause SW interrupts to be delivered through writes to the seteipnum* register or is the direction

By Ved Shanbhogue · #137 ·

Slides from today's AIA meeting (12-08-2021)

Hi All, Highlights from today's meeting are: 1) Two minor changes in AIA spec 2) Few changes in ACLINT related to MTIMER and SSWI devices 3) Made good progress on AIA Software Phase2 efforts Here's

By Anup Patel · #136 ·

Re: Proposal for ACLINT MTIMER groups

The mess is in breaking down MTIMER device into two devices MTIME and MTIMECMP. Anyway, I have updated ACLINT draft spec with following changes: A MTIMER device has two separate base addresses:

By Anup Patel · #135 ·

Re: Proposal for ACLINT MTIMER groups

I don't think there's any mess being requested. One HW constraint with the current proposal, IIUC, is that MTIME register addresses have a fixed relationship to a given set of MTIMECMP registers. Is

By Josh Scheid · #134 ·

Re: side effects are disallowed on reads of standard CSRs

Earlier I wrote: Since there seemed to be consensus for this plan (or begrudging acceptance), I've updated the AIA document: https://github.com/riscv/riscv-aia Look under "Releases" for the latest

By John Hauser · #133 ·

Re: side effects are disallowed on reads of standard CSRs

Siqi Zhao wrote: So the contents of CSRs can be nondestructively examined for debugging. Side effects may still occur on writes. You can see much of the discussion

By John Hauser · #132 ·

Re: side effects are disallowed on reads of standard CSRs

Not about AIA itself, but what is the reason behind this decision on no side-effect?

By Siqi Zhao · #131 ·

Re: side effects are disallowed on reads of standard CSRs

I agree, a warning would be wise. The suggestion to leave the *topei CSRs read-only and use *clreipnum would be fine, except for a couple of things: First, because many users are extremely sensitive

By John Hauser · #130 ·

Re: side effects are disallowed on reads of standard CSRs

That would be a pretty bad software bug by a programmer - that's going to result in flaky system operation. One of many bugs that a programmer could avail himself of. And one reflecting a poor

By Greg Favor · #129 ·

Re: side effects are disallowed on reads of standard CSRs

Hi Greg, Please see inline below … Regards, Anup From: Greg Favor <gfavor@...> Date: Friday, 23 July 2021 at 10:17 AM To: Anup Patel <Anup.Patel@...> Cc: John Hauser <jh.riscv@...>,

By Anup Patel · #128 ·

Re: side effects are disallowed on reads of standard CSRs

Keep in mind that this is effectively the same functionality and semantics as the "old" *claimei CSRs - just slightly changed and renamed. And with exactly the same intent and usage model. In other

By Greg Favor · #127 ·

Re: side effects are disallowed on reads of standard CSRs

Hi John, Please see inline below... Regards, Anup On 23/07/21, 6:43 AM, "John Hauser" <jh.riscv@...> wrote: The guardians of the RISC-V spec have recently decided that standard

By Anup Patel · #126 ·

side effects are disallowed on reads of standard CSRs

The guardians of the RISC-V spec have recently decided that standard RISC-V CSRs will not be defined to have side effects on reads. The AIA currently defines CSRs mclaimei and sclaimei to be

By John Hauser · #125 ·

Re: Questions/Comments on AiA version 0.2-draft

Thanks John. I have noted a few comments below. Yes, the AiA specification already assumes and supports use of hart local interrupts. So section 9.3.5 provides a recipe for the hypervisor to deal

By Vedvyas shanbhogue · #124 ·

Re: Proposal for ACLINT MTIMER groups

Typo correction in last statement: “[Anup] SOFTWARE can easily adapt to both above approaches without creating a MESS.” From: <tech-aia@...> on behalf of Anup Patel <anup.patel@...> Date:

By Anup Patel · #123 ·

Re: Proposal for ACLINT MTIMER groups

Please see my response inline below … Regards, Anup From: Josh Scheid <jscheid@...> Date: Tuesday, 20 July 2021 at 2:17 AM To: Anup Patel <Anup.Patel@...> Cc: "tech-aia@..."

By Anup Patel · #122 ·

Re: Proposal for ACLINT MTIMER groups

And also that those are separate system addresses, or not? That every MTIMECMP group has a "local" MTIME register, which is then designated as aliased or reference? Why do aliased MTIME registers

By Josh Scheid · #121 ·

Re: [RISC-V] [tech-unixplatformspec] [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Lastly, before I shut up, ... A key point in all this is that memory-mapped registers like MTIME/MTIMECMP will be very uncommon. Most registers, even if logically defined as 64 bits wide, can be

By Greg Favor · #120 ·

Re: [RISC-V] [tech-unixplatformspec] [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

In essence, is RV64 going to effectively outlaw ready use of common 32-bit "utility" AMBA bus standards in RV64 systems (especially since there will be a growing number of 64-bit memory-mapped

By Greg Favor · #119 ·

221 - 240 of 358

Home Hashtags Subgroups Terms