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

wjones at wdj-consulting.com wjones at wdj-consulting.com
Mon Feb 13 15:41:55 EST 2017

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 
which was auto generated from .vhm sources).
"Theses sources" refer to the previously open sourced J2 tarball (April 

>This has a pipelined multiplier
>and very wide (64 bit) accumulator, and also saturation logic.  It operates 
>a semi autonomous execution unit, off to the side of the rest of the 
>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 
>the instructions that this unit executes.
This sounds like quite a bit of work. I didn't consider that replacing w/ a 
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 
(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 
>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 
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 
>for the most part, the RTL, tools, and instruction set are the same as the 
>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 

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! :)


William D. Jones
wjones at wdj-consulting.com 

More information about the J-core mailing list