riscv / riscv-platform-specs Goto Github PK
View Code? Open in Web Editor NEWRISC-V Profiles and Platform Specification
License: Creative Commons Attribution 4.0 International
RISC-V Profiles and Platform Specification
License: Creative Commons Attribution 4.0 International
Currently the base spec says:
Memory accesses by I/O masters can be coherent or non-coherent with respect to all hart-related caches.
However, nothing is said about what software should do in that case. I believe the CMOs extension should be required in such a case, as otherwise software cannot work without adding SoC-specific cache management operations, which quickly becomes the kind of mess that platform specs are supposed to stop happening.
In section 2.2.7.2 of the Server profile, "System Date/Time", the explanation for GetTime()
sounds awkward:
"Must be implemented by firmware" is clear, but what is "to incorporate with the underlying system date/time mechanism" supposed to mean?
Not being a native speaker, I believe correct verb usage is to incorporate sth., not to incorporate with sth.
I am guessing what it really means is to expose the underlying system date/time mechanism?
Hi team,
I am looking into some descriptions in RISC-V of self/cross-modifying code (SMC/CMC), which is (quoted from intel x86 manual vol 3A, 8.1.3 "Handling Self- and Cross-Modifying Code")
The act of a processor writing data into a currently executing code segment with the intent of executing that data as code is called self-modifying code.
...
The act of one processor writing data into the currently executing code segment of a second processor with the intent of having the second processor execute that data as code is called cross-modifying code.
Software with just-in-time compilers relies on such behaviors heavily, such as OpenJDK [1].
The current RISC-V port of OpenJDK (ported from its AArch64 port) also uses such techniques. Some instructions (nop, jal) running on some reader harts may get dynamically patched by other writer harts (Of course on Linux there is __riscv_flush_icache
called after the CMC writing behavior). But it's unknown to me if the readers can observe a legal state, so I am searching if there are documents setting this patching
behavior as legal, that is, patching these instructions would not make some reader harts observe an "undefined behavior".
I didn't see much in the riscv-spec so I went to our riscv-isa-manual
github. Coming from the nearly same issue and its comment [2], I reached here, with finding [3]. I think it can reflect what I am searching for (it doesn't say the store operation rise up exceptions and clarifies the legality of the read is guaranteed to be in a clear state, without undefined behaviors, so I guess it might be an intel x86 alike statement as below that all instructions at runtime could be safely patched when they are properly aligned).
I can find statements from the arm-v8 manual that only nop
, bl
, b
, isb
alike several instructions could be safely cross-modified. No safety of cross-modifying other instructions is guaranteed, described in "B2.2.5 Concurrent modification and execution of instructions".
In [3] I found our statement got an update to To order older stores before younger instruction fetches, ...
. I don't know if the older stores
description could implicitly reflect whether RISC-V supports the CMC/SMC behaviors. I am a little confused about this.
The question is simple: is it legal to execute SMC/CMC behaviors on any instruction, that no interesting unpredictable state could be observed, in RISC-V's spec for now?
Thank you in advance!
Best,
Xiaolin
[1] http://cr.openjdk.java.net/~jrose/jvm/hotspot-cmc.html
[2] riscv/riscv-isa-manual#650 (comment)
[3] 38d0b4b#diff-e2e67320afc3dbcf884d10778f562bfa141048bbccbf7be067df8813a55a66fdL131-L137
In interrupt controller section of M platform, embedded systems are recommended to use PLIC, CLIC, or both as interrupt controller(s). However, APLIC have smaller memory map requirement than PLIC. Thus, I thought that APLIC is more suitable in embedded systems and may become an option for future interrupt controller of M platform.
The current platform spec says that...
On RV64I-based Unix-class systems the negative virtual addresses are reserved for the kernel.
However, at least on x86_64 the memory map includes a "guard hole" reserved for the hypervisor. Is there intended to be a similar cutout in riscv, and if so should that be indicated here?
The "UART/Serial Console" section does not say what size memory accesses are required to work for UART registers. I recommend that support be required only for word-size (4-byte) accesses, and that other sizes may possibly fail with an access fault or bus error.
The AMBA Advanced Peripheral Bus (APB) does not support reads narrower than word-size, and before 2010 did not support writes narrower than word-size either. If we say that byte-size and/or halfword-size accesses must be supported, then it's debatable whether a UART connected through even a recent APB can actually conform. In any event, there may be other buses in use, standard or custom, that can perform only word-size accesses, like older APBs.
Word-size accesses are obviously sufficient for interacting with the UART, so I can see no reason for the platform spec to require that other access sizes be supported.
Current Sstc extension does not seem to include a virtual timer offset. This will require clarification.
Section 4.7.3.4 describes behavior for No_Snoop bit but does not prescribe DMA coherence as a requirement. It shoud.
Great initiative!
I do however have questions about the requirements for the RVM platform, specifically the 32-bit version;
Is it realistic to require RV32G in order to comply with the RVM platform? It seems like a more natural choice would be RV32IMAF, as RV32D is pretty heavy on the floating-point for small microcontrollers (most Cortex-M devices don't even have double precision support in hardware, that's only available in the M55 and M7).
Also the C extension would make sense to include as embedded applications are quite sensitive to code size, but that's probably a different discussion worthy of its own issue...
This is a 3-step update for which I will be submitting a PR:
Once complete, the side-effect for anyone starting to use this repo locally will be that they'll need to learn to use Git Submodules. Plenty of useful information is here. But the key step is to issue a git submodule update --init
after a new clone or the first pull after this PR.
At key points in the future, we may want to use the git submodule update
to update to a new level because Submodules always "link" at a given commit level. (More discussion here as we work with this.)
If anyone has questions about the process, please free to let me know.
misa
If H extension is supported then the H bit must be writable.
For example, open-source Rocket-chip does not (yet): chipsalliance/rocket-chip#2841
The M platform description says that, to say CLIC is implemented, the original basic interrupt mechanisms must also be supported. That seems wrong - especially when the CLIC spec provides for the original basic mechanism not to be supported.
The OS-A platform spec used to have a requirement for strong point-to-point I/O ordering for most devices. It was deleted last year with the remark "All the points specified in supervisor.adoc are already described in the new revamped platform spec", but I cannot find any statement to this effect. The change was here: 3e12ad1#diff-1d563824326d2cf24a223ae5c45f6247f5fd9a553acff627370ddd8f9e64b031L16-L17
I think we just need to add the following clause: "Unless otherwise specified by a given I/O device, I/O devices are on ordering channel 0 (i.e., they are point-to-point strongly ordered)."
I see that there are now some different requirements for PCIe. That's OK; these statements don't conflict, because of the "unless otherwise specified" phrase.
Currently the spec says:
Platforms are required to provide an at least 10ns resolution 64-bit counter with strictly monotonic updates.
The hardware clock that drives the counter is required to operate at a minimum frequency of 10MHz.
but also:
For a counter with 10ns resolution the timebase-frequency value would be 100000000 (100 MHz) which would also be the minimum possible value for timebase-frequency. From the software perspective a unit increment of the mtime value would correspond to a 10ns interval. However the hardware clock driving the counter could operate at a lower frequency, thereby incrementing the mtime value by more than one unit per clock tick.
These are all contradictory; a 10MHz clock doesn't give a resolution of 10ns, and similarly if the clock is at a lower frequency than timebase-frequency, with the latter still reporting 100 MHz, and steps multiple values at a time then you're not going to have a resolution of 10ns since you never see an individual step.
Currently the supervisor spec says:
On RV64I-based Unix-class systems the negative virtual addresses are reserved for the kernel.
Why is this part of the platform spec? What addresses are used by the kernel and what addresses are used by userspace are entirely up to the kernel and not the concern of the platform, so unless I'm missing something it does not make sense to specify arbitrary implementation details.
Two abbreviations seem to be used for "Core-Local Interrupt Controller"
CLINT is the only one mentioned in the Terminology table at the top here: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#terminology
The specifications linked are:
Can/Should this be made more cohesive? CLIC
seems more in line with PLIC
.
The platform spec includes this proposed requirement:
Attempted use of corrupted (uncorrectable) data must result in a precise exception on that instruction with a distinguishing custom exception cause code.
This adds a non-trivial performance/area cost, and is a stronger requirement than other contemporary ISAs and system architectures.
While the README file references the project is licensed under the CC-BY-4.0 license and provides a link to the full license text. the lack of a LICENSE file prevent GitHub from recognizing the license.
I propose adding a plain text LICENSE file like the one used in the ISA manual.
I'm happy to add this into the project directly and will do so shortly. If anyone has concerns, please raise them.
Thanks,
-Jeff
The privileged spec describes that PMAs may be vacant. The current specifications are vague around handling of unpopulated (aka "vacant") memory. They must mandate a behavior, e.g. all zeros/all ones/error response
ECAM must be preserved in the face of OS re-enumeration of the PCI fabric. It should be noted that an OS/other SEE software may renumber downstream buses. When this happens, in an implementation composed from multiple independent root ports, it is necessary to ensure that the correct underlying fabric routing is preserved.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.