Public review for Non-ISA Specification: RISC-V Platform-Level Interrupt Controller

[Aaron Durbin]

Hello All,

We are delighted to announce the start of the public review period for RISC-V Platform-Level Interrupt Controller.

The review period begins today, September 2, 2022, and ends on October 16, 2022 (inclusive).

This Non-ISA specification is described in the PDF available at:

https://github.com/riscv/riscv-plic-spec/releases/tag/1.0.0_rc4

which was generated from the source available in the following GitHub repo:

https://github.com/riscv/riscv-plic-spec/

To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the GitHub repo. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and suggestions, will be gathered for review by the PLIC Task Group. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the Privileged Software HC will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Aaron Durbin, on behalf of Abner Chang (renba...@gmail.com)

[Ashish Dixit]

Chapter 4 is a single sentence stating "The memory map register width is in 32-bit"   (copied verbatim!)

Is this meant to state that all PLIC registers are memory-mapped of 32-bits each? Can one further assume that byte, half-word, double-word  or address-unaligned accesses are disallowed? Each implementation may decide to generate an exception, error or simply ignore such accesses?

[Abner Chang]

Hi Dixit,

Thanks for the feedback, I agree with you to add a clear sentence to this chapter that vendor can follow.

How about this,

"The memory map register width is in 32-bit, any non-32-bit access to these registers is disallowed. It may result in an exception or unexpected error depending on the implementation."

However, we may need the opinion from vendors on whether this sentence causes the extra HW/FW cost.

Thanks

Abner

Ashish Dixit 在 2022年9月7日 星期三凌晨4:55:56 [UTC+8] 的信中寫道：

[Sean Halle]

Hi Ashish, thanks for pointing this out.

Hi Abner, thanks for the reply.

Could we clarify the context a bit?  I am inferring that this is regarding the MMIO registers used to configure the PLIC, that were specified in Chapter 3, is that correct?  And I'm inferring that 32 bit was chosen as the least common denominator, so that both 32b micro-architectures and 64b micro-architectures can easily implement the PLIC without undue hardships, is that also correct?

If so, then I'm assuming what is meant is that 64b micro-architectures will do something like mask off the unused bits when accessing this MMIO register in the PLIC.  Is that right?

If all the above is correct, then it feels as though we would want some uniformity.  Perhaps the wording should include something along the lines of:

"The memory mapped registers specified in Chapter 3 have a width of 32-bits.  Micro-architectures that implement a data path that is wider than 32b shall use the lowest significant 32 data bits when reading and writing these registers."

It feels that it may be overly constraining to specify the consequences of non-conformance to the spec, as well as overly constraining to specify what is done with the most significant bits, and also overly constraining to give a specific bit width for wider micro-architectures.  However, it does feel important to specify that it is the least significant bits, as it complicates software compatibility if some wider (64b) implementations use higher bits and others use lower bits.

If desired, it may be helpful to add a "design background" comment as is done occasionally in the ISA specs.  Maybe something like:

"64b micro-architectures will likely simply mask off the upper 32b when accessing these MMIO registers in the PLIC."

Best,

Sean

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/af484c07-f4d1-42f7-a43d-c64080311b09n%40groups.riscv.org.

[K. York]

64-bit cores have a 32-bit architectural data access instruction - LW -, and the memory bus interface is left unspecified.

I'm reading the specification to say that programs must use the architectural 32-bit data access instructions, and whatever that translates to on the memory bus is what the PLIC should expect to receive.

A memory bus that delivers addresses to units with 64-bit (8 byte) granularity cannot implement this specification. If the full byte-granular address is delivered, then the PLIC can do whatever the memory bus specifies for returning 32-bit data on a 64-bit bus.

In other words, there cannot be a software compatibility hazard except with buggy implementations. Returning the data for a 32-bit read in the high bits violates the specification of the Load Word instruction. Writes and reads will not be coalesced in a way that hides their addresses because the PMAs for the region will say so.

Thanks,

~ Kane

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwD%2BAYbEfWDszKqXPF%3DB84rZ9x6gBcZpvpNmL0VjhJDVfAg%40mail.gmail.com.

[kr...@sifive.com]

There is no need to forbid non-32b accesses, and several downsides to
this mandate (added hardware, slower operation in some systems).

The PLIC was designed to require only 32b accesses to simplify bus
fabric designs, but other size accesses are not prohibited and can be
useful.

If an implementation does not support !=32b accesses it should
generate a bus error as with any other unsupported access to a device.

If tighter constraints are required on PLIC design to make software
portable, these should be expressed in a platform specification, not
in the base PLIC spec.

Krste

>>>>> On Tue, 20 Sep 2022 22:21:45 -0700 (PDT), Abner Chang <renba...@gmail.com> said:

| Hi Dixit,
| Thanks for the feedback, I agree with you to add a clear sentence to this
| chapter that vendor can follow.

| How about this,

| "The memory map register width is in 32-bit, any non-32-bit access to these
| registers is disallowed. It may result in an exception or unexpected error
| depending on the implementation."

| However, we may need the opinion from vendors on whether this sentence causes
| the extra HW/FW cost.
| Thanks
| Abner

| Ashish Dixit 在 2022年9月7日星期三凌晨4:55:56 [UTC+8] 的信中寫道：

[Krste Asanovic]

The existing arch specs already describe how 32b accesses work in an RV64 system.

There is no need to replicate in the PLIC spec.

Adding a redundant partial description here would be problematic.

Krste

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwD%2BAYbEfWDszKqXPF%3DB84rZ9x6gBcZpvpNmL0VjhJDVfAg%40mail.gmail.com.

[Ved Shanbhogue]

Few comments:
1. Whether the bytes are rotated into position or the implementation uses
byte enables to convey the valid bytes on the fabric need not be in this
specification. Implementations may need to make the right choices.

Some implementations may even have a narrower bus than 4 bytes. For example,
the bus may transfer data a byte at a time. It would then be expected of such
implementation to ensure there are no side effects of this choice - for example,
a write to the complete register may have side effects and it would be expected
of the implementation to gather all bytes of the transfer before causing the
side effect. Again not something this specification should be expected to
specify - besides perhaps the need to support 32-bit single-copy atomicity
when the architectural acccess was a 32-bit store.

2. Not needing to support partial read/write will have hardware simplifications
by not needing read-modify-write. So if there is no useful case for needing
such accesses from software usages it may be beneficial to not require it.

3. The specification is silent on the endianness of the registers. Was that
planned to be specified in a later platform specification?

regards
ved

>> https://github.com/riscv/riscv-plic-spec/releases/tag/1.0.0_rc4 <https://github.com/riscv/riscv-plic-spec/releases/tag/1.0.0_rc4>

>>
>> which was generated from the source available in the following GitHub repo:

>> https://github.com/riscv/riscv-plic-spec/ <https://github.com/riscv/riscv-plic-spec/>

>>
>> To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the GitHub repo. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.
>>
>> During the public review period, corrections, comments, and suggestions, will be gathered for review by the PLIC Task Group. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the Privileged Software HC will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.
>>
>> Thanks to all the contributors for all their hard work.
>>
>> Aaron Durbin, on behalf of Abner Chang (renba...@gmail.com <>)
>>
>> --
>> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org <mailto:isa-dev+u...@groups.riscv.org>.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/af484c07-f4d1-42f7-a43d-c64080311b09n%40groups.riscv.org <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/af484c07-f4d1-42f7-a43d-c64080311b09n%40groups.riscv.org?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org <mailto:isa-dev+u...@groups.riscv.org>.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwD%2BAYbEfWDszKqXPF%3DB84rZ9x6gBcZpvpNmL0VjhJDVfAg%40mail.gmail.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwD%2BAYbEfWDszKqXPF%3DB84rZ9x6gBcZpvpNmL0VjhJDVfAg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>--
>You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

>To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/535C450B-4CDC-445E-BA96-3E20F588DD73%40sifive.com.

[Samuel Falvo II]

On Fri, Sep 23, 2022 at 6:10 AM Ved Shanbhogue <v...@rivosinc.com> wrote:
> 2. Not needing to support partial read/write will have hardware simplifications
> by not needing read-modify-write. So if there is no useful case for needing
> such accesses from software usages it may be beneficial to not require it.

Using byte-enables, already available on the bus, allows for sub-word
accesses without read-modify-write cycles.

> 3. The specification is silent on the endianness of the registers. Was that
> planned to be specified in a later platform specification?

RISC-V is, in the absence of any other platform-specific feature,
understood to be little-endian. It seems reasonable that a PLIC
standard designed to work with RISC-V would also use little-endian
representation.

But, if subword addressing is not supported, it's irrelevant. As long
as bit N of a register aligns with bit N on the data bus, endianness
doesn't matter.

--
Samuel A. Falvo II

[Andrew Waterman]

On Fri, Sep 23, 2022 at 7:33 PM Samuel Falvo II <sam....@gmail.com> wrote:

On Fri, Sep 23, 2022 at 6:10 AM Ved Shanbhogue <v...@rivosinc.com> wrote:
> 2. Not needing to support partial read/write will have hardware simplifications
>     by not needing read-modify-write. So if there is no useful case for needing
>     such accesses from software usages it may be beneficial to not require it.

Using byte-enables, already available on the bus, allows for sub-word
accesses without read-modify-write cycles.

> 3. The specification is silent on the endianness of the registers. Was that
>     planned to be specified in a later platform specification?

RISC-V is, in the absence of any other platform-specific feature,
understood to be little-endian.  It seems reasonable that a PLIC
standard designed to work with RISC-V would also use little-endian
representation.

It is worth stating explicitly. We did recently standardize the mechanisms to support big-/bi-endianness. You’re of course right that RISC-V has a historical and likely long-lived little-endian bias, but we should err on the side of clarity going forward, I think.

But, if subword addressing is not supported, it's irrelevant.  As long
as bit N of a register aligns with bit N on the data bus, endianness
doesn't matter.

--
Samuel A. Falvo II

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3Dso%3D2Ex9myveZp-TM9y_wLW9Q29rQ20s79bE2jopB_vsHyw%40mail.gmail.com.

[Allen Baum]

This captured my attention:

Using byte-enables, already available on the bus, allows for sub-word accesses without read-modify-write cycles.

<Pedantic hat on>

Which bus is "the" bus? There is no RISC-V mandated or even favored bus, so that's a statement that a pendant wants to read.

I'd reword that a tiny bit, though that doesn't really change your argument. 

<I will take off my pedantic hat now.>

[BGB]

On 9/24/2022 12:36 AM, 'Allen Baum' via RISC-V ISA Dev wrote:
> This captured my attention:
>
> Using byte-enables, already available on the bus, allows for

> sub-wordaccesses without read-modify-write cycles.

>
>
> <Pedantic hat on>
> Which bus is "the" bus? There is no RISC-V mandated or even favored bus,
> so that's a statement that a pendant wants to read.
> I'd reword that a tiny bit, though that doesn't really change your
> argument.
> <I will take off my pedantic hat now.>
>

True in my case as well (nevermind the specifics of which ISA my core is
used to run; and PLIC is N/A in my case).

I suspect the bus is likely to vary a fair bit from one implementation
to another, and in any case doesn't necessarily look much like the
abstract memory model presented to the programmer.

Note sure how much my approaches here resemble what others have done.


In my case, byte or half-word access only really exists within the L1 cache:
RAM is only accessed at a 128-bit granularity (L1<->L2);
L2 <-> DRAM is currently 512 bit.
MMIO is accessed at a 32 or 64 bit granularity.
Misaligned access, or non-standard widths, are undefined.

Decided to leave out going into the memory map.

But, basically, within the physical memory map, RAM-like access, and
MMIO-like access, are divided into different address ranges.

At the level of the L1 cache, it may see some of these special ranges
and invoke some special behaviors (accessing MMIO or bypassing the MMU,
if enabled).


RAM-like ranges:
The L1 cache fetches cache-lines (128-bit in this case), and can support
arbitrary access sizes at arbitrary alignment by extracting values from
or inserting them into these cache lines.

All the bus sees in this case are the cache lines, and usually only when
a cache-miss or similar occurs.

There is a Volatile/No-Cache sub-mode, which does similar, except that
the L1 will attempt to automatically flush and evict the cache-line
following the access in question (such that it gets written back in a
timely manner).


Typically the L1 caches talk to an L2 cache, which in turn talks to the
RAM controller and similar over its own specialized bus interface (which
in turn talks to an external DDR2 chip or similar). In my case, the L2
cache translates between the logical 128-bit lines, and the 512 bit
lines used for the DDR interface (mostly because there is less overhead,
and thus higher bandwidth, when moving 512 bits to/from the DDR module
than if moving 128 bits).


However, the bus and L1 caches remain 128 bits mostly because 256 or 512
bits is significantly more expensive.

In this case, the CPU core itself contains:
The execution pipeline;
The L1 caches;
The TLB (separate entity on bus, not integrated into L1's);
Etc.

In this case, the bus used (for the main CPU core to talk to things
outside itself) is basically a "slotted ring bus", where:
Each node on the bus has an "input side" and an "output side";
By default, stuff gets forwarded directly from the input to output
A message on the bus may be acted on (added/removed/modified).
Everything is plugged together into a big ring.
Unhandled messages cycle the ring until they can be handled.

Where, each message holds, say:
Payload data (128-bits);
Target address (48-bits typically);
Request / Response Code (16-bit);
Origin Node and Sequence Number (16-bit).

There may be multiple requests active at the same time on the bus.

Things like interrupts and similar are also passed around as messages on
this ring bus. Otherwise, the ring mostly holds NOP messages.


Was faster than some simpler bus designs, and also seemed a bit simpler
than something like AMBA/AXI (generally AXI looks complicated/expensive).


The MMIO range:
Tells the L1 cache that it is dealing with an MMIO device, which invokes
different handling for the load/store request (L1 sends a discrete
request and waits for a response). The core itself uses a shared bus
interface for both RAM and MMIO, but the way they behave in these cases
is significantly different.


Once the message gets to it, an MMIO request moves off the main bus and
onto a separate "MMIO bus", which all the MMIO devices are basically
plugged into.

Currently, the MMIO bus narrows the address to 28 bits and the payload
data to 64 bits, and uses a generally different bus design.

A select few devices (such as the main display device) also have a
connection onto the main ringbus (mostly used so that it can access
RAM-backed VRAM via the L2 cache).


Specifics for an actual external peripheral bus are a different manner
(doesn't exist in this case). Could come up with something if I needed
to link FPGAs together or something (probably something along similar
lines to a bus protocol built on top of SPI or something).

[Iztok Jeras]

In my experience with embedded SoC (with a 32-bit CPU), all peripherals only supported 32-bit accesses (for both write and read).

I am not sure but I remember Nios II did the same. I actually kind of remember seeing this approach in Nios II, and then implementing it on ASIC SoC designs.

There definitely are registers (those with side effects for example) where accessing less than the full bus width would require special considerations and therefore extra documentation.

I would not say ignoring byte enable bits has a significant effect on area, but it definitely has a significant effect on code complexity, it is much easier to write register access code without byte enable support.

So I would default to supporting this restriction.

Lately I was designing a system bus based on QMEM (used in OpenRisc) and I was thinking about power consumption caused by data bus toggling. This toggling can be reduced by accessing less than the full bandwidth and avoiding changes to other bytes.

So considering power consumption and performance considerations for remote busses with some serialization, there definitely are some use cases to allow less than full width access to peripheral registers. The question is, whether this is worth the extra considerations, their documentation and RTL complexity.

[Ved Shanbhogue]

On Fri, Sep 23, 2022 at 07:33:08PM -0700, Samuel Falvo II wrote:
>On Fri, Sep 23, 2022 at 6:10 AM Ved Shanbhogue <v...@rivosinc.com> wrote:
>> 2. Not needing to support partial read/write will have hardware simplifications
>> by not needing read-modify-write. So if there is no useful case for needing
>> such accesses from software usages it may be beneficial to not require it.
>
>Using byte-enables, already available on the bus, allows for sub-word
>accesses without read-modify-write cycles.

So I was not suggesting there would be a read-modify-write
on the bus. That would be even more involved to support
atomicity among multiple initiators. I was noting that the
register file itself, accessed over said bus with byte
enables, whether built using an sram, flop array, latch
array, etc. would need to support a read-modify-write
operation even if the bus can signal the bytes to write and
the bytes to preserve using the byte enables.

>
>> 3. The specification is silent on the endianness of the registers. Was that
>> planned to be specified in a later platform specification?
>
>RISC-V is, in the absence of any other platform-specific feature,
>understood to be little-endian. It seems reasonable that a PLIC
>standard designed to work with RISC-V would also use little-endian
>representation.
>
>But, if subword addressing is not supported, it's irrelevant. As long
>as bit N of a register aligns with bit N on the data bus, endianness
>doesn't matter.

So it is irrelevent if the said register is a dumb storage.
If the data in that register is written by the hart and is
consumed by the PLIC logic then they both must have a common
notion of the endian-ness of the data.

[BGB]

On 9/24/2022 2:38 PM, Iztok Jeras wrote:
> In my experience with embedded SoC (with a 32-bit CPU), all peripherals
> only supported 32-bit accesses (for both write and read).

This makes sense for 32-bit.

As noted, in my case, my peripherals allow 32 or 64-bit access, but I am
dealing with a primarily 64-bit core design.


Originally, the bus was 32-bit only, and most MMIO devices only allow
32-bit access.

Some devices gained 64-bit access for performance reasons. Currently,
the video-display device and SDcard SPI interface also allow 64-bit access.


For the SDcard SPI interface, the 64-bit port is mostly to allow a
special operation which transfers a block of 8 bytes at a time, rather
than a single byte at a time. This was mostly (because of MMIO bus
access latency; and the overhead of this using strictly sequential
access), accessing the SPI interface "one byte at a time" became a
significant bottleneck (even compared with the overhead of bit-serial
communication with an SDcard).

In effect, the 8-byte transfers resulted in around an 8x reduction in
needing to check the status flag register, update the control register,
or load/store the SPI interface's data register. Where, data is
transferred to/from the SDcard typically in 512 byte sectors.

This is, absent any sort of "more clever" mechanism for reading/writing
data (no DMA burst transfers or similar, just ye olde polling IO).

For a 32-bit machine, the equivalent would be doing 4 byte bursts over SPI.


For something like UHS modes, to make any effective use of this (versus
using SPI mode), would probably need some sort of special hardware-level
interface (probably a special cache and effectively memory-mapping the
SDcard into the physical address space or something; treating it like a
sort of non-volatile memory space).

> I am not sure but I remember Nios II did the same. I actually kind of
> remember seeing this approach in Nios II, and then implementing it on
> ASIC SoC designs.
> There definitely are registers (those with side effects for example)
> where accessing less than the full bus width would require special
> considerations and therefore extra documentation.
> I would not say ignoring byte enable bits has a significant effect on
> area, but it definitely has a significant effect on code complexity, it
> is much easier to write register access code without byte enable support.
> So I would default to supporting this restriction.
>

I would assume, in any case, that requiring byte-oriented access to
devices, would put an undue burden on things (compared with only
allowing access at defined widths).

> Lately I was designing a system bus based on QMEM (used in OpenRisc) and
> I was thinking about power consumption caused by data bus toggling. This
> toggling can be reduced by accessing less than the full bandwidth and
> avoiding changes to other bytes.
>

Yeah, though unused parts of the message can be left at a default state.
Say, anything headed for MMIO is kept zero-extended (and NOP states on
the bus are mostly zeroed).


In my case, I am not sure if many other people are using rings.

The ring seemed to allow a nice way to both interconnect things, and
also to handle multiple ongoing requests at a time (messages moving
along at one position per clock cycle, and one can keep dumping requests
onto the bus so long as there are empty slots to drop them into).

In effect, the communication mechanism also providing its own implicit
storage.

One could argue about the latency cost of sending a message around a
ring, though in my experience, this latency cost is somewhat less of an
issue than the cost of being limited to one request at a time.

In some cases can transfer almost 200MB/s between the L1 and L2 caches
at 50MHz, which implies latency isn't killing things too badly;
theoretical peak bandwidth for this bus being 800MB/s at 50 MHz, but
this would be pretty much impossible in practice.

In any case, it is significantly faster than my original bus design
(which peaked out at around 16MB/s here). Basically, the cost of needing
to deal with sending each request sequentially (and also some additional
costs of state transition and propagation time through the crossbars, etc).


Pretty much everyone else seems to be using crossbars and FIFOs or
similar from what I can gather.

I avoided using a FIFO oriented design, as needing them at nearly every
connection point (within a star topology or similar), seemed like it
would be too complicated and expensive.


Whereas, without FIFOs or similar, a crossbar bus would necessarily turn
into "one request at a time", which in turn becomes a significant
bottleneck (my early bus worked this way, it was slow).

A bus where requests and responses are handled using multiple lanes,
with sequential burst transfers and FIFO buffers needed pretty much
everywhere, was not something I found particularly attractive
(needlessly complicated).

> So considering power consumption and performance considerations for
> remote busses with some serialization, there definitely are some use
> cases to allow less than full width access to peripheral registers. The
> question is, whether this is worth the extra considerations, their
> documentation and RTL complexity.

Yeah, an external bus is an open question.


One possibility (assuming pins/etc were less of an issue):
Data{0/1/2/3}, Clock, Gnd, Vcc
With both an In and Out side.

Then say, on the rising clock-edge, send 4 bits, and another 4 bits on
the falling edge.

Then, data is, say:
'FF': Used as a general "NOP" signal, similar to FFI;
Messages could consist of a tag/format byte, followed by, say:
Operation, 8 or 16 bits;
NodeID+Sequence, 16 bits
Address, 32|48 bit
Data, 32/64/128 bit
Possible: Check Byte (verifies that message arrived intact).

The tag byte would indicate the sizes of the other fields.

There would be a dedicated module for encoding/decoding messages from
this interface, possibly dropping them onto an internal ring, or taking
messages off the ring that are addressed to another node (messages
directed within the same node being left on that node's bus).


If, say, a message to a 32-bit address with 32-bit data takes ~ 16
bytes, a 12MHz bus could move around 3MB/s. It would be slightly more
efficient with 128-bit messages (~ 8MB/s at 12MHz).

A 25MHz bus could move 6MB/s, but this would likely require ribbon cable
rather than say loose wires or similar.

Ribbon cable could probably be able to handle such a bus at 25 or 50 MHz
or similar (assuming DDR signaling), or 50 or 100 MHz if SDR.


Assuming wire-lengths are kept roughly equal, travel length and
propagation time shouldn't be too big of an issue assuming each
connection has its own clock. However, assuming a global clock would not
hold up well much over fairly short distances.


One annoyance is the (standard?) PMOD interface on FPGAs only really has
8 data pins, so both an input and output connection with 4 data lines
would not fit onto a single PMOD (so, one would need two PMODs).

Using 1 or 2 data pins would be easier, but would reduce data rate.
Self-clocking and 8/10b is possible, but adds its own issues (would make
more sense for a higher-speed serial bus).

Could also consider the possibility of bidirectional links rather than
unidirectional links (with both sides able to drive the data pins in
order to transmit). This would allow for both ring and star topology
(clock is naturally pulled-up, but pulling the clock line low signals
that one side or the other is transmitting). For a ring, unidirectional
links would be assumed.


If one wants to throw a RasPi or similar into the mix, then the issue
comes up that bit-banging IO on the RasPi is not very fast, and its
range of built-in options are fairly limited. The RasPi would likely
need to talk to an FPGA or similar via SPI to be able to plug into this
style of bus.

Direct connection to a RasPi (via bit-banging) could probably work if
one limited the bus to kHz territory along that link (or having a
"return clock" special case pin, where the RasPi updates the return
clock pin whenever it is able to process a bit; and allows the links to
negotiate clock-speed to some extent).


Though, granted, many other bus designs are possible.

[Earl Killian]

IMO, I think the discussion has gotten a bit far afield of the original query. While some of things being discussed are interesting, I would still like to see the original point resolved. I believe the original question was whether PLIC implementations are required to support byte, halfword, and doubleword writes, and doublword reads. If the PLIC is being accessed only by RISC-V LW and SW instructions, then byte-write enables are not required in its implementation, and the ability to read 64-bit values are not required. If such a restriction were made, some implementations might choose to only support 32-bit read/write, which is presumably a simplification. Other PLICs might choose to support a wider variety of read/write sizes (e.g. if there were 16-bit microcontrollers present in the system doing smaller writes), but these days that seems less necessary.

[Allen Baum]

Exactly what Earl said. We are not architecting the bus; we architecting the ABI

This is a Risc-V spec, and Risc-V is a 32 (or 64 and eventual 128)b architecture.

 If someone needs a 16-b microcontroller, they won't be using a Risc-V, so that's moot.

If it's Risc-V and they want to use a 16b interrupt controller, then it's not a PLIC, and that's moot also.

From a software interoperability standpoint, we probably need to be quite clear which solution(s) are expected.

The PLIC spec defines all registers to be at 32b boundaries, and all consist of either a single field (>32b wide) or 32 1 bit fields.

Being able to address those at less than 32b width just isn't useful.

That seems like a fine restriction: 32b aligned loads and stores.

It's easy to understand, easy to implement, easy to program, easy to enforce in HW with a PMA entry, and has minimal (if any) downsides.

In the one case where a PLIC needs a RMW sequence (the Claim register), it defines the register to have a side-effect on the read to avoid the need.

If an implementation can perform narrower accesses: that's fine, but 

SW that depends on it may not be interoperable with off-the-shelf IP if it takes advantage of it,

And there's nothing to be gained if it does, so why would anyone do that?

Note that some bus implementations can automatically break up long reads and writes into separate transactions, 

and recombine them at the other end. That is irrelevant, because it is invisible to SW and invisible to the device.

On Sat, Sep 24, 2022 at 3:14 PM Earl Killian <earl.k...@arilinc.com> wrote:

IMO, I think the discussion has gotten a bit far afield of the original query. While some of things being discussed are interesting, I would still like to see the original point resolved. I believe the original question was whether PLIC implementations are required to support byte, halfword, and doubleword writes, and doublword reads. If the PLIC is being accessed only by RISC-V LW and SW instructions, then byte-write enables are not required in its implementation, and the ability to read 64-bit values are not required. If such a restriction were made, some implementations might choose to only support 32-bit read/write, which is presumably a simplification. Other PLICs might choose to support a wider variety of read/write sizes (e.g. if there were 16-bit microcontrollers present in the system doing smaller writes), but these days that seems less necessary.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/AD2AB40C-19A8-4FBD-9000-E31CC6D704C7%40arilinc.com.

[Sean Halle]

Good discussion.  In the end, we need concrete text.  

Taking another stab at it:

"The memory mapped registers specified in Chapter 3 have a width of 32-bits.  The bits are accessed atomically."

Design note:

"For software compatibility, it is expected that software running on architectures wider than 32b use the (code-visible) least significant 32b when reading and writing the PLIC registers.  For architectures narrower than 32b, it is expected that the code construct the 32b register contents with little endian addressing."

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DCBKntu9LTpGXBz64WzfDf0kKbOqe53snHZhLGyaOs7rQ%40mail.gmail.com.

[Allen Baum]

Um, "architectures narrower than 23b"? You mean bus architectures? RISC-V ISA is never narrower than 32b.

But, the key word is "atomicallly"; once you say that, everything else really follows.

[Ashish Dixit]

This wording looks good to me.

Thanks, Sean.

- Ashish

- Ashish

On Sun, Sep 25, 2022 at 11:49 PM Sean Halle <sean...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwDLBN1_ERLbs9v1c_MqG1RaN5BVFPaOWD4rTba_4m9DFWA%40mail.gmail.com.

[Sean Halle]

Hi Allen, yes, you are correct.  The thought was to future proof.. and there is no reason this PLIC cannot be used with non-RISC-V ISAs, why not cover the bases? 

[K. York]

I'd say "accessed atomically with the LW and SW instructions", to avoid any confusion with the A atomic memory operations.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwDLBN1_ERLbs9v1c_MqG1RaN5BVFPaOWD4rTba_4m9DFWA%40mail.gmail.com.

[Abner Chang]

Yes, this sounds to me more clear. 

"The memory-mapped registers specified in Chapter 3 have a width of 32-bits.  The bits are accessed atomically with LW and SW instructions."

Does anyone have an objection to this sentence?

I may also combine chapter 4 with chapter 3.  Chapter 4 looks empty.

Thanks

Abner

kane...@gmail.com 在 2022年10月12日 星期三晚上10:06:35 [UTC+8] 的信中寫道：

I'd say "accessed atomically with the LW and SW instructions", to avoid any confusion with the A atomic memory operations.

On Sun, Sep 25, 2022, 11:49 PM Sean Halle <sean...@gmail.com> wrote:

Good discussion.  In the end, we need concrete text.  

Taking another stab at it:

"c

[Abner Chang]

RC5 released.

https://github.com/riscv/riscv-plic-spec/releases/tag/1.0.0_rc5

Regards,

Abner

Abner Chang <renba...@gmail.com> 於 2022年10月22日 週六 上午10:42寫道：

You received this message because you are subscribed to a topic in the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/isa-dev/Pio-7A8W1Kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f838e9b6-7d82-47ed-8dfc-0d882d86f7d4n%40groups.riscv.org.