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

[wjones at wdj-consulting.com]

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?

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

>This has a pipelined multiplier
>and very wide (64 bit) accumulator, and also saturation logic.  It operates 
>as
>a semi autonomous execution unit, off to the side of the rest of the 
>(integer)
>pipeline, and therefore includes it’s own state machine.  One could ‘simply’
>write a stub that returns 0 on y.mach y.macl and deasserts y.busy to get a
>working core without that block.  IIRC, gcc only knows how to generate some 
>of
>the instructions that this unit executes.
This sounds like quite a bit of work. I didn't consider that replacing w/ a 
single-cycle
multiplier wouldn't be as simple as "drop a non-pipelined multiplier in". 
Based on
how you describe it, this unit is similar to how MIPS handles multiplies and 
divides
(using a special register/state that must be saved on exception)?

>So, similarily, one could make a
>simple block that just does those, perhaps using a generic to select the 
>number
>of cycles of latency (that is, the width of the hardware multiplier).
Let me see if I understand this correctly: I could alternatively take the 
pipelined
multiplier as-is, trim some functionality, and stick it directly into the 
integer pipeline (as opposed to
being its own separate unit), and just stall during a multiply?

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

Thanks for your help! :)

Sincerely,

--
William D. Jones
wjones at wdj-consulting.com