diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 50 |
1 files changed, 44 insertions, 6 deletions
@@ -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) |