tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Thanks Greg. This would be helpful to not prevent an implementation to engineer a solution but does not force an implementation to do so. I think this makes sense. Totally agree. regards ved

By Ved Shanbhogue · #1557 ·

Re: MTIME update frequency

Absolutely. I was only suggesting a 1ns resolution and not a 1ns update rate.

By Ved Shanbhogue · #1556 ·

Re: MTIME update frequency

Literally, such a "loosely synchronized" implementation would not be compliant with RISC-V architecture and its tight synchronization requirement. As Darius noted (below), that is just one way to

By Greg Favor · #1555 ·

Re: MTIME update frequency

Note that ARM SBSA did not mandate a 1 GHz update rate; it only mandated a 1ns resolution - and explicitly acknowledged that updates may be at a lower rate using counter scaling. Greg

By Greg Favor · #1554 ·

Re: MTIME update frequency

I took the opportunity to raise this with Andrew and Krste (who authored the text in question) as to the intended and proper reading of the following arch spec text: Before summarizing their response,

By Greg Favor · #1553 ·

Re: [PATCH 4/6] Reduce the number of mandatory PMU events.

Fixed. Thanks.

By atishp@... · #1552 ·

Re: [PATCH 5/6] Add more clarity about privilege mode optionality.

My bad. Fixed it.

By atishp@... · #1551 ·

Re: MTIME update frequency

I read them separately and I think the text carefully used "counter" and "clock" carefully for the first sentence and second sentence carefully. Placing the synchronization requirement on the clock

By Ved Shanbhogue · #1550 ·

Re: MTIME update frequency

It seems that this comes down entirely to semantics of what a "tick" means in this context. If 1 tick = 1 count = 10ns then it violates the spec, whereas if 1 tick = 10 count = 100ns then it complies.

By Jonathan Behrens <behrensj@...> · #1549 ·

Re: MTIME update frequency

Please read what I said. I said it *effectively* forces an implementation to have a 100 MHz clock. With the current wording in the draft specification, multihart implementations must do one of the

By Darius Rad · #1548 ·

Re: MTIME update frequency

The ISA specification also says: The execution environment should provide a means of determining the period of the real-time counter (seconds/tick). If the period of the counter is in units of

By Darius Rad · #1547 ·

Re: MTIME update frequency

This states synchronized to one tick of the real-time clock. It does not state it has to not differ by 1 count. regards ved

By Ved Shanbhogue · #1546 ·

Re: MTIME update frequency

The requirement seems to come from the Zicntr extension described in the base (unprivileged) spec. I'll let somebody else say whether incrementing mtime by +10 counts as 1 tick or 10 ticks.

By Jonathan Behrens <behrensj@...> · #1545 ·

SBI specification status update

Hi, The RISC-V international has recently established a ratification policy[1] for non-ISA specification as well. All of the non-ISA specifications (e.g SBI, psABI, ACLINT) will have to go through the

By atishp@... · #1544 ·

Re: MTIME update frequency

Which section of the specication should I look at for that requirement? The only requirement I could find is from ACLINT spec: "On a RISC-V platform with multiple MTIMER devices residing on the same

By Ved Shanbhogue · #1543 ·

Re: MTIME update frequency

I think the argument is that you technically violate the ISA spec if you have two cores and you increment mtime on the first core by +10 then a fraction of a nanosecond later update the second core's

By Jonathan Behrens <behrensj@...> · #1542 ·

Re: MTIME update frequency

I largely agree. While the clock "tick" is one ulp, an update can increment time by, for example, 10 ticks. (The same is true in ARM SBSA/BSA/etc.) Greg

By Greg Favor · #1541 ·

Re: MTIME update frequency

The resolution requirement (whether =10ns or <=10ns) doesn't force a 100 or 100+ MHz clock. Only the >=10 MHz update rate forces a 10 MHz clock - which is a pretty modest requirement for OS-A-class

By Greg Favor · #1540 ·

Re: MTIME update frequency

The current specification says that the MTIME values seen by two HARTs to be not apart by more than 1. It does say the MTIME must always increment in units of 1. I do not think the specification

By Ved Shanbhogue · #1539 ·

Re: MTIME update frequency

No, it does not address my concern. As you said, that requirement was already there, and my concern applies to the requirement as is, although increasing the resolution will exacerbate the

By Darius Rad · #1538 ·

301 - 320 of 1857

Home Hashtags Subgroups Terms