From 45aea8c5394b363edd79c0c28203d0f2f11b99eb Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Thu, 10 May 2018 11:16:46 +0100 Subject: [PATCH] add ipc extension --- ipc_extension.mdwn | 41 ++++++++++++++++++++++++++++++++++++ isa_conflict_resolution.mdwn | 6 ++++++ 2 files changed, 47 insertions(+) create mode 100644 ipc_extension.mdwn diff --git a/ipc_extension.mdwn b/ipc_extension.mdwn new file mode 100644 index 000000000..ab1ec1c02 --- /dev/null +++ b/ipc_extension.mdwn @@ -0,0 +1,41 @@ +# IPC Extension + +see Tony Brewer's (Micron) slides. + +idea: copy POSIX send/recv/select semantics + +dependency(?): scratch/CAM memory extension + +* MSTORE: message send; send message to a target hart) and store it in + its message-buffer. Traps when target buffer is full. +* MLOAD: message load; load message from local message buffer. Traps + when buffer is empty. +* MFLUSH(?): flush local buffer +* MSELECT: check if send (or receive) can succeed (or block) + +MSEND can be like ST, but I chose to have a return value to indicate +whether the send was accepted (i.e., copied into xmit buffer). this +enables sharing of resources at the sender (future senders will be +denied until the xmit buffer has space). + +MRECV has two versions, blocking and non-blocking. the non-blocking +version allows the hart to do a bit more work before checking whether +data has arrived. the blocking version waits until data is received. + +to improve upon the messaging system I described, there would need to +be backing storage in main memory for the CAM data. perhaps the CAM +needs to operate with an eviction policy based upon oldest-first. main +memory would then store anything that is evicted. that way any values +in the CAM that aren't used right away will migrate into main memory; +it is acceptable to move them there because this is already a high + +Maybe the *newest* message should spill to memory instead? This keeps +messages in FIFO order and could be easier to implement -- MSEND traps, +supervisor transfers the message to memory and sets a bit in the target's +task state indicating "RX queue overflow". When the target task finally +does drain its RX queue, and that bit is set, MRECV traps to permit the +supervisor to reload the hardware queue from the memory overflow area. + +This avoids needing background DMA for the message buffers in hardware +and allows supervisors to fully implement the overflow queues, rather +than forcing a hardware-imposed structure. diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 03aef29ef..b0a14fcde 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -558,6 +558,12 @@ The following conversation exerpts are taken from the ISA-dev discussion > instruction decode must be unambiguous, it merely expands every opcode with > extra bits from a "select" CSR. +## (5) Krste Asanovic on clarification of use of opcode space + +> A CPU is even free to reuse some standard extension encoding space for +> non-standard extensions provided it does not claim to implement that +> standard extension. + # References * -- 2.30.2