[J-core] MMU-Design

[D. Jeff Dionne]

Page table walking can be implemented, it's just an FSM (these sorts of things are a little easier in VHDL than Verilog, but I digress and others will disagree).

The problem is it's large.   I think BGB is correct, and there needs to be options for not including that sort of hardware.   The number of TLB entries, and the sizes of them available, will 
are a large change in the achievable performance here.   The TLB fill code is a place where you really want it to be fast, and have the normal working sets cause that code to execute infrequently.   Likely, it should live in SRAM, on chip.

Cheers,
J.

> On Dec 3, 2017, at 03:47, BGB <cr88192 at gmail.com> wrote:
> 
>> On 12/2/2017 10:57 AM, Fabjan Sukalia wrote:
>> Hello,
>> 
>> I'm curious about the memory management unit in j2, as it is needed to port Debian to j-core. The last I read on this mailing list was that the design of the MMU will be discussed during a meeting in Japan. 
>> Are there any new information that can be shared with the community? Will it have a soft-mmu, like MIPS and LM32 have, or a hard-mmu like in x86? Also, will the design be compatible to the MMU in SH-4?
>> 
> 
> AFAIK:
> * J2 doesn't have an MMU ( and presumably wont? )
> * presumably, the MMU would likely be for different cores ( J4 / etc... ).
> 
> 
> can't speak for J-Core here, but have noted:
> * for many use-cases, an x86 style hard-MMU is preferable;
> * however, a soft MMU is easier to implement in hardware (*1).
> * the existing OS's (such as Linux) seem to basically just emulate a page table on SH4.
> * the existing SH4 MMU design has a lot of "unnecessary complexity".
> ** in the form of features and memory-mapped structures which make little sense to be visible.
> ** Linux does not appear to make use of these, but I could be wrong here.
> 
> 
> what seems like a sane option, at least, from my POV (as an outsider):
> * optionally mandate the use of a conventional page-table style layout;
> ** only mandated if the use of a firmware or "hard" MMU is enabled.
> ** left it as "undefined" if something different is done while hard-MMU flag is set.
> ** page table bit-layout is to be kept basically equivalent to the Linux page-tables.
> * implemented as a soft MMU in hardware.
> ** likely significantly stripped down vs the SH4 design.
> ** presumably, the registers/... are basically the same as SH4, but specifics differ.
> ** likely omits MMIO visibility for the TLB and caches.
> * potentially, the MMU is (optionally) moved into firmware.
> ** say, there is an MMU flag which indicates where TLB miss ISR's go.
> *** say: Set=0xA0000400, Clear=VBR+0x400.
> ** if there is an (optional) hardware MMU, this flag would also enable its use.
> ** an OS supplied TLB ISR could still exist as a fallback (if the feature is not supported).
> ** by extension, things built as ROM would need to supply a TLB ISR though.
> ** the firmware ISR or hard-MMU would instead generate a Page-fault ISR.
> *** say, as using the TLBMISS exception code, but transferring control to VBR+0x100
> * ...
> 
> 
> but, as noted, these are just outsider thoughts (from someone working on an independent side-project...).
> 
> *1: I was initially pretty much on the "do a hard MMU" side of the fence, but a very brief attempt at doing page-walking logic in Verilog pushed me over to the soft-MMU side of things ( pretty much anything that requires performing multiple sequential steps is a horrible PITA; and "microcode" ended up just sort of decaying into "just generate an ISR" and "casually overlook that using certain instructions within an ISR will effectively crash the CPU..."; but the "lame jokes" never end here, and this was by no means the worst of it... ).
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core