[J-core] Microcontroller variant of J-Core?

[Rob Landley]

On 5/17/20 3:10 PM, Andrew Pullin wrote:
> Hi folks,
> 
> I was turned onto J-Core after I saw it mentioned in Twitter. The project seems
> interesting.
> 
> Is there currently, or could there potentially be, a configuration of J-Core
> targeted to implementing microcontroller class devices?
> No MMU, no linux, just "bare metal" and libc.

Have a look at https://github.com/j-core/j-core-ice40

> I did see some other mailing lists posts mentioning the lack of an SRAM/SDRAM
> controller.
>
> Hooking that up to the BRAM generators/macros in modern FPGAs might be an
> interesting solution.

We're using fpga sram for lots of stuff. In fact all the memory the ice40
implementation has is 2 different kinds of sram blocks, the j2 register file on
xilinx is sram, the L1 cache is sram...

If you mean bolting on _external_ sram, I think the limiting factor is that's
not how we wanted to spend the available iopins in any of the FPGAs we're using.

> (but being an FPGA novice, this is beyond my skill level at the moment)
> Or in the case of the ice40K, just connect directly into the moderately sized
> dedicated SRAM.

We've been hunkered down focusing on customer stuff during the pandemic
lockdown, and have been terrible about communication. Sorry about that. We've
telecommuted up several cool new things, and should write them up and try to
publish more on github...

Unfortunately, while our management's been very clever about finding new
projects we can do via telecommuting during the pandemic, they came with some
NDAs and press release embargoes and such which means I'm not supposed to talk
about ANY of it until after it ships. Annoying, but plans changed out from under
us and we had to adapt a bit suddenly. We ARE still supposed to eventually
publish most of the new stuff, but not here first, and not via me.

> The curiosity comes from what I perceive as a trend in the FPGA/IC sector at the
> moment:
> Seeing that ARM is making their M0/M1 cores available for free trial suggests
> that they feel the pressure of RISC-V.

Nah, it's because the superh patents expired a few years back, which Arm had
licensed to create the thumb instruction set, meaning chips implementing the
thumb instruction set are now significantly cheaper, which put the thumb-only
cortex-m* into a new price category that ARM is trying to take advantage of by
pumping up the volume. Cortex can now be a "low margin, high volume"
microcontroller without having to pay third party royalties on every chip sold.
(ARM still gets paid, but Hitachi/Renesas doesn't get tens of millions annually
in patent license fees on top of that.) And the BIG news there is that FDPIC for
Arm finally got merged into gcc and Linux, which makes Linux cortex-m a lot cleaner.

RISC-V always struck me as open source's itanium. It's a solution in search of a
problem that tries to make a self-fulfilling prophecy out of marketing itself as
"inevitable" the same way Hillary Clinton did in 2008 _and_ 2016. But I'm the
first to admit I'm biased here. :)

> And there is always Microblaze in certain toolchains, but that is a licensed IP
> product married to a specific ecosystem.

Microblaze isn't a product, it's a firmware package designed to sell FPGAs.
Xilinx never wanted to make an ASIC out of it, that's not what it's for. But
half the people who make xilinx FPGA boards bolt either an atmel or a cortex-m
onto the side of the FPGA to load the control it (otherwise reflashing is really
bricky), and unless the microblaze is significantly more capable than that ASIC
why bother except as a learning exercise?

The morning Jeff and I left Japan (due to Coronavirus being about to screw up
air travel), we met with fab people to talk about making J2 ASICs. I blogged
about it at the time:

  https://landley.net/notes-2020.html#18-02-2020

Predictably that's on hold now due to the pandemic ("pan" means "bread",
https://xkcd.com/2296/), as is half of everything worldwide, but eh. I was
scheduled to fly back to Japan March 17: this did not happen. We're doing what
we can from where we are, but as the man said, "and that my liege is how we know
the earth be be banana shaped". And as the Doctor's Daughter's Mother said "we
will be restoring normality as soon as we are sure what is normal anyway":

  https://www.youtube.com/watch?v=_Iw8qUTLBok

> In particular, I am interested in a system that blurs lines between firmware and
> hardware definition, where a minimal core would drive a set of
> application-specific peripherals, potentially dramatically reducing the
> complexity of the firmware.

Talk to Jeff, he's been doing that for 30 years. :)

> And application-specific instructions would be the ultimate extension thereof.
> A free and in-the-clear minimal 32b MCU core with gcc/llvm/libc support could be
> an enabler for that goal.

J-core has an extension bus thingy that lets you implement new instructions as
new hardware blocks without modifying the existing VHDL. Jeff's explained it to
me a couple times but I haven't poked at that part. So far we mostly we just
memory map our I/O devices, but we were working on some new instructions in
November before our todo list played 52 pickup. (If I blogged about it then,
have fun. If not, I dunno what I'm supposed to say now, see embargoes above.)

> Do the authors & experts here think that J-Core might be a candidate for that
> application?

Sure.

> And is there a more current distribution or repository than the "Download" link
> on the website? The latest there appears to be from 2016.

The git repo I pointed to above has our ICE40 port. There's BEEN plenty of new
development (since then and before then), and I hope you get to see it soon, but
I have no idea what "soon" means in the current context.

  https://www.youtube.com/watch?v=GtExvYM66YY

> Thanks,
> Andrew Pullin

Rob