[J-core] The main goals for J2

[Rob Landley]

On 06/11/2016 09:24 PM, Daniel V wrote:
> Hi!
> 
> Found this project today. And it's looks impressing, solving a lot of
> issues regarding hardware design. Primarily for getting to market
> fast, and avoiding unnecessary license fees.
> 
> Is the primary goal of this, to get a fast way to implement custom CPU
> instructions, in a hardware design? that also can run C code and Linux
> out of the box?

That's a Jeff question. "What our our goals" is a very long list. Which
goal(s) are primary is... you kinda have to do all of them at some
point? Sequencing issue, really?

More custom SOC peripherals than custom instructions, I expect. We have
DSP plans and such, but the point of a CPU is to run a known instruction
set that a compiler can output to run software. We reused an existing
instruction set (as the patents on the old technology expired) for a reason.

We've talked about goals a bit in our talks (the talks page has a decent
video of our most recent one, at ELC, and some practice talks we gave at
the Linux Jamboree to a smaller audience).

Asking what jcore is for is a bit like asking what Linux was for back in
the 90's. The S-curve of Moore's law has been flattening out for a few
years now, so we have to make better use of the transistors we've got,
and applying open source to hardware development is the obvious way to
do that. Cheap low-end FPGA systems (like the Numato boards, but also
Lattice ones) are now capable enough that widespread participation is
possible.

One of the things we want with jcore is get to the point where your fab
has a basic jcore mask on hand already. You need a processor for your
hard drive or intelligent keyboard or wireless doohickey? Throw in a
jcore for free. If you commission a mask and fab a run of chips,
donating the mask to the fab afterwards so people can run more of those
chips is an option. This is oneof the advantages of us NOT being GPL,
you can combine our stuff with your stuff and just have fun with it.
(Although Jeff wants a BSD license with advertising clause, so people
have to somehow squeeze the text of the BSD license onto the back of
each chip's creamic packaging if they're properly paranoid about legal
issues. I'm still trying to talk him around to 0BSD...)

Running C and Linux was our first big goal, which is now achieved. We
have a roadmap expanding up and down from there.

  http://j-core.org/roadmap.html

I should probably expand on that at some point, but j0 is something we
need to add a target to the Arduino IDE for, j3 adds mmu and a few
instructions.

j4 adds full-is sh4 compatibility, and that's probably where we add
multi-issue (executing multiple instructions per clock cycle), and
expand the FPU to properly do IEEE double without a software math
library. (Although we may _never_ do the old thing's dsp stuff because
it just doesn't come up much and we have our own.)

And then the 64 bit version (j64) is new, but we mapped out what it
should look like back in April...

> Looking at different MCU designs, they fail at providing a SDRAM
> interface,

J1 is SDRAM. And we have SDRAM internally in our SOC already?

> and providing a USB-bootloader in ROM (that could program
> flash or SD-card, or boot from code uploaded to RAM).

Our ROM bootloader is in the source, feel free to extend it how you like.

> Another thing,
> is failing to provide LVDS interfaces onboard, in conjunction with
> timers and DMA. There can be reasons for things like that is not done,
> but would still be useful.

That part's not my area.

> One problem that I have seen in the past with things like these, is
> that the tool chains is to hard to install, or lacking documentation.

I've documented a lot on j-core.org and I need to document more. There's
a whole second bitstream compiler toolchain in the works (Targeting
lattice boards, and properly open source although portions of it are
sadly gplv3 but nobody sane will ever ship binaries of it, so that
shouldn't come up. It does  mean that WE can't offer precompiled
versions of the toolchain though.)

And on the software side, there's links in http://j-core.org/news.html
to the new stuff which needs a proper write-up on its own page.

(Not this week though. Several of the existing j-core engineers are
getting together in Austin and having a sort of summit thing.)

> Looking at the MCU market, the ships is almost "free" like in free
> beer, but time-consuming to configure and to read through the
> documentation, weird installations, and custom programmers. Arduino
> solved that, by adding a 10 times the real cost, to solve the weird
> issues with MCU designs, like not having a convenient way to program
> the chips, expensive C compilers, and lacking ways to expand RAM and
> Program Memory. If you can start it from a SD card, and add SDRAM to
> the MCU, only there would be a great improvement, and would greatly
> reduce the final cost for a product, by getting to market fast,
> without the arduino bloat.
> 
> And if the tool chain was working out of the box, that J2 would be a killer.

For xilinx processors we need the xilinx toolchain, which is free as in
flash plugin, with all that entails. There's a page on installing it,
and it sucks.

However, for Lattice processors we hope to be able to glue nvm's vhdl
frontend to yosys' Lattice code generator backend. The largest lattice
fpga we've found can just about host the smallest most stripped down
j-core image we can do, for the Arduino market it's still pretty
exciting and in future it may scale up further.

  http://j-core.org/news.html#05-06-2016

Hang on, I know there's more recent newson it than that... Ah, right, in
private email, didn't get forwarded to the list. Sigh. Lemme ping the
nvm maintainer for permission to forward his email...

(And we really need to get the Turtle kickstarter off the ground but
we've all had an attack of life that cost us a few weeks. The prototypes
are really nice, we're just distracted at the moment. That's our LX25
board that can host SMP j-core, those boards will cost more than the
Numato ones but should be under $100 each, maybe we can get it down to
around $70? Working on it...)

> I get the impression, that the engineers using MCU:s are quite
> unwilling to change what type of MCU they are using. And I think it's
> because the tool-chains tend to be a pain to set up. And thats
> probably why those FPGA companies, can sell expansive licenses for
> their "own" soft cores. People cant get their head around how to use
> anything else, and they need that C-compiler.

We're trying to teach people! we're trying to make it easy! There's so
much more work to do but we're all juggling a dozen balls each trying to
keep the lights on...

> Thanks for making this available. It's looks like one of the most
> promising projects I have ever seen. Please let us know, where help is
> needed, or wanted or justified.

Glad you like it. :)

Anybody who wanted to poke at gluing nvm to yosys, that's something that
really needs to happen (see the list threads) that nobody's had time to
do here yet...

Pointing out to me where the documentation needs to be expanded would be
good. (What topics are we not properly covering yet? I already know we
need a proper VHDL tutorial...)

Rich Felker doing his own stab at the mercurial->git conversion so we
can post the VHDL history on github. (I tried but kept hitting different
assumptions between hg and git when it comes to nested subrepos,
nobody's made a proper tool for this yet and the innards of SCMs are
fiddly. I was fine until I had to merge branches and then it all went
pear shaped...)

> // Daniel V.

Rob