[J-core] Adding SH2/SH4 support to LiteX using J-Core?

[Rob Landley]

On 02/13/2017 02:41 PM, wjones at wdj-consulting.com wrote:
> Sorry for the delay, I have some more questions :).
> 
>> Please keep in mind that this is not the j-core repo, the RTL checked in
>> to your github is a snapshot of post processed files suitable for test
>> synthesis
>> using new tools.  That is, it’s configured a certain way, and certain
>> of those
>> files are the output of auto generation tools.  It’s not the sources,
>> it’s
>> an intermediate output.
> I was told in IRC conversation (I don't think there's a log for it) that
> this is
> what is called "J1". Should I not be using this source at all- i.e. it was
> a mailing-list-internal tarball not meant for widespread usage?

I'm the one who told you. :)

Unfortunately the j-core full repo conversion/cleanup so it can go up on
github has been stalled by the same "attack of life" that's been
distracting everything else for a few months. It's working its way
through but I'm still not sure what the actual deadlines are. :(

This was the only public release of the J1 work done so far, and it has
the advantage (for your purposes) of being a standalone build. (Yes
there's some generated files in there, but that's what you need for a
standalone build.) It seems like the best base for what you're trying to
do. Integrating any changes you make back upstream into _our_ stuff will
require extra work on our part, but that's our fault for not having
finished our housecleaning yet. :P

That tarball is mostly just the processor (and I think serial port), not
the other peripherals or SOC stuff (dram controller, etc). But I think
that's what you wanted to plug this processor into your existing build?
[this space intentionally left emoticonless]

>> These sources have a MAC unit included (contained in mult_pkg.vhd and
>> mult.vhd,
> which was auto generated from .vhm sources).
> "Theses sources" refer to the previously open sourced J2 tarball (April
> 2016)?

More or less.

>> This has a pipelined multiplier

That's a Jeff question. :)

The _plan_ for J1 was to microcode the multiplier. Our public J1 design
discussions were last year, mainly two threads, one in May:

  http://lists.j-core.org/pipermail/j-core/2016-May/000164.html

And one in August:

  http://lists.j-core.org/pipermail/j-core/2016-August/000289.html

>> The main J2 repo (SEI internal, as Rob always points out, at the
>> moment) has a
>> few changes to the co-processor interface, and therefore the AIC.  I
>> think that
>> for the most part, the RTL, tools, and instruction set are the same as
>> the last
>> full opensource drop (provided it has CAS.L).
> I'm not sure if the previous open source drop has CAS.L, but I think it
> does.

The second one should. Dunno about the first.

(We have stuff running at 62.5 mhz internally (and 87 mhz on kintex,
which is an FPGA line done on a higher-resolution fab) and have been
_meaning_ to do a third drop for a while, but what we really need to do
is a push a proper repo with history to github with a third _tag_, and
that's a bigger lump of work. Which turned into one of those "the first
80% of the work takes 80% of the effort, the last 20% takes the other
80% of the effort" things. In that context, we already did the first 80%...)

> The reason that mailing list tarball was suggested to me was because I
> don't need the entire J2 distribution for
> LiteX/MiSoC; I only need the CPU core. LiteX/MiSoC will take care of
> generating all the peripherals and bus logic.
> I may need to modify the bus interface slightly to "play nice" with
> Wishbone (or add a cache), but I can safely
> strip out a lot of the current distribution. Linux is an end goal with
> LiteX/MiSoC as well, but the idea is to also
> use it as a moderate-to-high performance microcontroller. With that in
> mind, should I just take the current
> J2 tarball and strip out what I need? Or perhaps a stripped down version
> of the source proper already exists?

Also Jeff questions.

The tarball I pointed you at seemed to me to be the best place for you
to get started from what we've already released: it was created to
provide the NVC developer with a standalone test case of the build we
were trying to do (our goal was to create a fully open source toolchain
combining NVC with YOSYS that could target an ICE 40).

It boots our processor (trimmed down to fit into Lattice's FPGA budget)
and runs the self-test ROM, with output to serial. And the NVC developer
did eventually get his simulation mode to build and run our code, and
get the same waveform output as the xilinx tools. (Which is where it got
shelved, we haven't had time to poke at it since.)

I don't want _us_ to be a bottleneck for _you_. We have giant piles of
todo items that we really look forward to doing, but our engineering
cycles have been tied up on the customer side of the house for several
months now.

Rob