[J-core] Roadmap (was Re: j2 llvm repo?)

[Rob Landley]

On 02/07/2017 03:29 PM, John Paul Adrian Glaubitz wrote:
> On 02/07/2017 10:26 PM, Rob Landley wrote:
>> Whatever method you're using to push to your repository seems to be
>> forcing me to delete my copy and re-clone it each time, which is kind of
>> inconvenient...
> 
> That normally happens when changes are force-pushed into the repository.
> 
>>> It hasn't been tested that much and still remains an educational-purpose
>>> backend.
>>
>> Let me know when you're ready for outside testing, I look forward to
>> trying it...
> 
> How much is actually missing for sh4? I would love to have this in Debian.

I'm fairly certain Jeff could do a better explanation of all of this,
but here's a stab at it (none of which is cannon, this is a software guy
talking about what hardware guys said over dinner months ago, not merely
half-remembered but half-understood in the first place):

My understanding is it's not the amount of development that's the
problem, it's that the back of the envelope calculations say we probably
can't fit j3 into an LX9 FPGA (at least not the first couple versions),
so it's been punted until Turtle is out so people have something
reasonable to run it on.

There's three main things in j3: adding an MMU, floating point support,
and some misc new instructions. (There's other stuff like multiple DRAM
controller instances for >256M memory, making use of the DMA engines,
and so on. But that's SOC not processor.) The new instructions aren't a
big deal, the FPU is a largeish transistor count (especially to do
double precision), and the MMU isn't actually that _complicated_ but it
adds extra signal routing that takes up a lot more FPGA cells than the
increase in gate count would suggest. (And all the timing closures have
to be rethought. Solvable, but nontrivial. I think the xilinx tools did
something obviously non-optimal and it could benefit from layout work,
or something?)

But the main reason we haven't gotten to most of this yet is the
hardware engineers got buried in 6 months of $DAYJOB customer
productization stuff based on the existing j2 SOC design that _should_
be working their way through soon? (The definition of "soon" is a
management question, not an engineering question.) There's been some
quick "Is this trivial to do? No? Back on the todo list" stabs at
non-customer stuff, but mostly small things. We should have cycles to
properly advance the roadmap again in "a few weeks". (I've asked: "few"
is like "soon".)

I believe the main reason we've split "j3" from "j4" is that j4 is
multi-issue (executing two instructions per clock cycle), which is a big
deal at the design level and we _know_ that's a lot of work. (The Japan
contingent seems excited about getting started on it, but we haven't
opened that can of worms yet beyond a couple whiteboard sessions to
scope it.)

What gets moved between j3 and j4 otherwise is a judgement call, we
could sequence the todo list several ways. The roadmap and the todo list
are at a different granularity: we could maybe implement the MMU without
the FPU or vice versa and do a release that way. (And MAYBE it's
possible to fit an MMU without FPU into an LX9, but we haven't managed
it yet? I think you'd have to sacrifice the cache to make space, and our
first stab at an MMU design was integrated with the cache, or something?
I'm still not a domain expert here, I just ask everybody questions about
what they're doing when I get the chance...)

We also don't want too many instruction set versions floating around out
there confusing the compiler people, if we can help it. We have
--with-cpu=j2 right now, we'd like to keep versions to a minimum. Should
the FPU have separate 32 bit and 64 bit modes: from a VHDL build
perspective and fitting into less FPGA space, sure why not? From a
toolchain/standardized instruction set perspective: ick, pick one. So
what configuration granularity level we implement beyond the first
release is a judgement call we haven't had to make yet. (There's been
talk of menuconfig in the VHDL build, which would itself be rather a lot
of work to implement...)

The other thing is we want to get our repository properly up on github
before doing too much more major design work. The questions in the last
paragraph are something the community should be able to weigh in on, and
doing development behind closed doors is not where we want to be long-term.

My own work is mostly on the software side, and my open-source-side todo
list right now is getting a toybox release out, working with Rich to get
a musl-cross-make release out, flushing my kernel patch queue this merge
window (have initramfs honor CONFIG_DEVTMPFS_MOUNT and so on), getting a
mkroot release out (which involves moving the kernel build and qemu boot
script stuff Aboriginal Linux used to do into a mkroot-style script),
present on all of this at ELC later this month so I can point people at
a video
(https://openiotelcna2017.sched.com/event/9Ith/tutorial-building-the-simplest-possible-linux-system-rob-landley-se-instrumentscom)
and then update the j-core website to have new build instructions using
current versions of all of the above.

The previous paragraph is one big dependency chain where I can't do a
mkroot release until I have the toybox and musl-cross-make releases it
uses, and really don't want to update website documentation to tell
people "grab a git snapshot du jour" instead of a release version.
(Releases are important. Trying out the release version first means you
mostly hit _known_ bugs...)

*shrug* Working on it...

> Adrian

Rob