start experimenting with processor grids

1 files changed, 44 insertions, 6 deletions

diff --git a/README.md b/README.md
index 6bf8707..a50938b 100644
--- a/README.md
+++ b/README.md
@@ -1,15 +1,53 @@
 # gran
 
-Gran is a toy granular full system simulator,
-taking heavy inspiration from [gem5](https://www.gem5.org/).
+Gran is a toy granular full system simulator, taking heavy inspiration from
+[gem5](https://www.gem5.org/).
 
-Currently there are a couple example components, including
-`simple_mem` for atomic memory accesses, `simple_bus` for non-coherent
-atomic transfers between components and `simple_riscv32`, a simple
-rv32i processor.
+Currently there are a couple example components, including `simple_mem` for
+atomic memory accesses, `simple_bus` for non-coherent atomic transfers between
+components and `simple_riscv32`, a simple rv32i processor.
 
 # Building
 
 + `make`
 
 Add `RELEASE=1` to enable optimizations.
+
+# manycore
+
+Idea: Have a grid of x/y width, where each node has three 'axes', i.e. if the
+address matches the node, pass the message to whatever is at that node (think of
+it like a miniature system I suppose?), otherwise check x, send it in that
+direction, otherwise check y, send it in that direction, otherwise check if
+message should be transcended, i.e. sent to some other cluster.
+
+Each address is 64 bits, split in half. The lower 32 bits is the offset within
+the node, and the upper 32 bits are split (again) in twine, something like x1 y1
+x2 y2 where each x or y is eight bits, specifying a node in an x/y grid. x2/y2
+specifies the lower cluster, with x1/y1 upper cluster. The idea is that a
+complete system would consist of cards that contain one cluster, clustered
+together. So a 'supercomputer' could be up to 65536 cards, with each card having
+a cluster of 65536 nodes. Each node is a compute unit, probably a single core,
+possibly with associated memory or devices like UART, whatever.
+
+Currently I'm imagining that each node also has a control region that can be
+written to with commands like 'drop all cache entries that containt address xyz'
+or 'wake up' (to enable userspace mutexes, that would be massively cool)
+
+The current focus would be to enable lightweight userspaces, full-blown
+hardware-assisted virtual memory is costly to implement (as in takes up too much
+space in hardware), but I'd still want to be able to run a command line and
+generic programs on the system. One idea would be a capability-based system,
+sort of like CHERIoT, though it has some drawbacks like having to keep track of
+the valid capabilities in separate memory or as part of ECC.
+
+Another approach that I'm currently thinking of is having a *very* simple
+region-based memory protection scheme, where instead of paging we have a TLB of,
+dunno, 64 regions that the core is allowed to access. If the core tries to
+access a region outside of those regions, the kernel is trapped to and can then
+insert the requested area into the regions or kill the process or whatever. This
+is *similar* to virtual memory in other systems (particularly MIPS), but would
+be range-based rather than page-based. If I wanted to use OpenASIP, I probably
+wouldn't be able to use interrupts, and we would either need a separate
+coprocessor to handle these kinds of exceptions or implement a tree walker in
+hardware (unsure how much extra area it would take)