[J-core] Route to J1: Was: Re: Jcore mailing list and tutrle board

[Rob Landley]

On 07/12/2017 08:12 AM, David Summers wrote:
> Hi Rob,
> 
> What would be the reason for J1 to go via ice40 rather than direct to asic?

To start with, "can we strip our design down to fit in the biggest
Lattice chip we can find" is where J1 initially came from.

We were trying to cobble together a fully open source VHDL toolchain,
and the pieces we found targetted Lattice instead of xilinx, so we used
that to send test cases to the developers of the toolchain pieces. (Nick
of nvc fixed a _lot_ of bugs we sent him. His stuff simulates j1 just
fine now.)

Once we'd done the work potential users and use cases started coming out
of the woodwork, but the initial driver was the desire to eventually get
away from proprietary hardware toolchains.

> Yes cost is an issue, development though you could do on your current
> boards.

Development _is_ done on our current boards...?

My understanding is that the main differences between J2 and J1 are:

1) No hardware multiplier (microcoded instead),
2) No DRAM controller (you use sram instead),
3) all the SOC I/O devices except the serial port switched off.

These can be individually configured in your build, if you want a j-core
without the multipler but with the dram controller you can tweak our
build system to get that, but when we say "J1" we mean the tiny thing
where we switched everything off to get the size down as far as it would
go without actually removing instructions.

We've built j1 with _both_ the xilinx ICE toolchain and nvc. (I don't
think we ever filled in all the glue code between nvc and yosys to do
elaboration, it's one of the many todo items that got buried while we
deal with customers thing to bring products to market.)

> So ice40 vs asic only come up during production of devices. When going
> into production only reason to go for ice40 is if the market is small
> enough to not justify an asic.

There was some talk internally about using an ice40 in turtle instead of
the atmel boot processor (I think it can load _itself_ from spi flash?),
but the brickability issue means we'd need to lock it down to running a
ROM image (or open the jtag can of worms), and we already had the atmel
working...

The main attraction of using j1 in ice40 for turtle would be complete
elimination of proprietary hardware in the device.

> I'd have though the choice was between going into production of j1, vs
> the arm route of letting 3rd parties use the j1 design in their own
> chips, for own needs.

J1 is basically a name for a configuration of the j-core SOC build. J2
is the name for another configuration of the j-core build. You could mix
and match them if you want to get your hands dirty with our build system.

Our initial ASIC target is the configuration that exercises more or less
all the hardware we've implemented so far, to prove _everything_ works
in ASIC. :)

(More or less = we haven't redone the prefetch unit to work with the
instruction cache yet, and it would probably be enough of a performance
win to be worth doing but it's out of scope for this ASIC.)

We have plans to redo the build system to make it more flexible, both to
target other FPGA boards and to make feeding stable reproducible code
drops to ASIC fabs (with all the elaboration and such done) easier to
do.  But it's the kind of janitorial work that has to wait for a gab
between putting out customer fires.

> Out of interest, what else would be stripped from J2 to make J1, I think
> we have so far:
> 
>   * Hardware multiply, etc (or rather doing multiply in one clock)

I think it's more like 3 clocks? I'd have to look it up...

The shift and add thing has a worst case of 33 clocks multiplying 32 bit
numbers. So 10x slower on that instruction:

  http://users.utcluj.ro/~baruch/book_ssce/SSCE-Shift-Mult.pdf

(Of course you only have to shift-and-add the bits that are set, so when
all the remaining bits are zero you can stop early, so with this method
multiplying smaller numbers is faster than big ones...)

>   * DRAM controller
> 
> Is anything else descoped?

Well there's some knock-on effects (without the dram controller you can
also drop the cache controller, sort of thing). And it doesn't have the
other I/O devices like sd card or ethernet.

Rob