[J-core] MMU-Design

D. Jeff Dionne Jeff at SE-Instruments.com
Sun Dec 3 00:35:14 EST 2017

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.


> 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?
> * 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

More information about the J-core mailing list