Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Sat, 15 Mar 2025 17:46:37 +0000
Organization: Rocksolid Light
Message-ID: <f2cb846242dbfcef1efa59b92763a965@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <YyFAP.729659$eNx6.235106@fx14.iad> <6731f278e3a9eb70d34250f43b7f15f2@www.novabbs.org> <AUHAP.61125$Xq5f.14972@fx38.iad> <748c0cc0ba18704b4678fd553193573e@www.novabbs.org> <2YJAP.403746$zz8b.238811@fx09.iad> <53b8227eba214e0340cad309241af7b5@www.novabbs.org> <3pXAP.584096$FVcd.26370@fx10.iad> <795b541375e3e0f53e2c76a55ffe3f20@www.novabbs.org> <vNZAP.37553$D_V4.18229@fx39.iad> <aceeec2839b8824d52f0cbe709af51e1@www.novabbs.org> <eM_AP.81303$8rz3.7843@fx37.iad> <vr2nj9$2goqe$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="323896"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$W4rZ3F2lGbxzgSLcDCqQFec8kuj6p5qo/KK2OOJBdRKVsxkmuqjQC
Bytes: 4255
Lines: 54

On Sat, 15 Mar 2025 2:10:48 +0000, Robert Finch wrote:

> Okay, all of this MSI-X stuff is starting to percolate into my brain.
> Coming up with a lighter-weight version of MSI-X for Q+. MSI-X has more
> capacity than is needed for the Q+ SoC. I desire something in between
> the simple and the complex. Interrupts are complex in multi-master
> systems.

Interrupts should utilize a message pathway already used by other
"system things". This eliminates any cost "ON" the interrupts
themselves.

Secondly, you want to be in a position where is someone chooses Q+
as their main CPUs, that they are not hindered in building large
systems using it.

> Q+ SoC has just 32-bits for the IRQ message payload data as many devices
> are 32-bit and IRQ messages are passed on the 32-bit response bus. That
> means a full I/O address cannot be used as it would be too large. As the
> message data, the I/O device supplies the vector number (12-bits) and
> interrupt controller number (6 bits). Specific interrupt controllers are
> targeted rather than an I/O address as targeting requires only six bits
> rather than a 32+ bit I/O address. Currently there will be only one
> interrupt controller in the system. Interrupt controllers could be
> designed to do other things like log to memory.

Under advice of council (EricP), I punted HW vectoring--which removed
a couple of pointers from the device:function control block along with
restrictions on where said table is, and on what alignment it is.

> Each interrupt controller has a base addresses and length for the vector
> tables so they may be located in system RAM (DRAM). The interrupt
> controller takes care of fetching the vector and broadcasting the vector
> to a specific CPU core.

There are situations where you want any 1 from a set of cores to "take"
the interrupt, rather than targeting one core (which may be busy at the
time.

>                         The target CPU core is programmable in the
> vector table. The vector contains 128-bits of information (almost same
> format as MSI-X) and identifies the ISR address and processing core.
> 32-bits of data may also be supplied in the vector table entry.
>
> To simplify things, the current interrupt controller contains the vector
> table in BRAM in a compressed format which supports 512 vectors for each
> operating mode. (2048 vectors total). The vector table is mapped into
> the MMI/O space. The interrupt controller reads from its internal vector
> table and directly supplies the CPU with the vector on a dedicated bus.

Those kinds of details have been punted to SW.

> I had the thought of supplying an instruction to the CPU rather than an
> address, ala 8080. Normally this would be a JMP instruction to the ISR.
> Other instructions may be useful like task-switch or interrupt return.