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

Andrew Pullin pullin at berkeley.edu
Mon May 18 06:04:36 UTC 2020

Wow, all very interesting and informative. Some thoughts follow.
Broadly: I looked at the ice40 repo and and it still seems a little 
impenetrable to me given my novice skill level.
But I still see big potential in making a free-and-in-the-clear core an 
off-the-shelf component.

On 5/17/2020 4:50 PM, Rob Landley wrote:
> 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.

Yeah, I really meant: make a functional MCU core with existing resources 
on-chip, in a configuration that mimics what you'd find in a mid-range MCU.

Although MCU's with SDRAM/PSRAM certainly exist out there for graphics 
applications. And all the midsize FPGA eval boards I have include an 
SDRAM (e.g. Digilent Arty) or DDR3L (e.g. OrangeCrab, ECP5).
That's part of the configuration space that I was thinking might be 
possible to span, from a resource equivalent of an M0 (on-chip) to an M7 
(off-chip, and enough IO to support the RAM).

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

Linux Cortex-M? That's ... interesting.
Having just gone through a job search, I have seen that "embedded" 
encompasses both the Linux and the microcontroller world, and few (if 
any) people have both in their skill stack.
I wasn't aware there was a push for a hybrid or a middle-ground solution 
like that...

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

Yes, now you're really driving into the core of my curiosity:
As I am sure you know, the division between CortexM+RTOS and "Linux with 
DDR" really divides the embedded device world.
In the robotics/hobby space, the combination of CortexA+Linux e.g. Raspi 
and a bare-metal MCU for sensor/motor control is entirely standard, but 
still a pretty messy landscape of technologies.

I am not targeting ASIC production, more like trying to take a step back 
from those standard solutions and see what might be possible now, given 
that previously exotic technologies are in reach in terms of complexity 
and cost constraints. Zynq+softcore as the next step in Raspi+STM32, 
something like that.

To be lofty about it: What Arduino did for microcontrollers in the past 
10-15 years, I see FPGA tech approaching a similar inflection point in 
accessibility and use.

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

Well, RISC-V is on my radar because it is pushing into the 
microcontroller embedded space a bit. Vendors are supporting it very 
early, since they see signs that it might supplant ARM due to being 
"free" (I think). Chinese industry has clearly invested heavily in it 
for their Application Processor class of devices.
When IAR and Segger are both supporting it before IC's are even 
available, that's notable.

That's also some of the source of my nebulous idea and interest in the 
reconfigurable computing space:
The promise of RISC-V was that you can put a little element of 
firmware-driven control into your system anywhere you want, so maybe 
replacing a high-clock MCU with an ice40 and specific peripherals might 
be better, faster to put together, lower NRE's, etc.

For example: If the SiFive folks bundled an RV32i core as a piece of 
"Vivado IP" that could be dropped in a block design for a Zynq or other 
7-series, connected to AXI and a QSPI I/O, and debugged easily, I think 
some heads could be turned.
That is a personal projected I wanted to try and accomplish, but, again, 
not sufficiently skilled yet. Looking at J-Core was along the same lines.

>> Do the authors & experts here think that J-Core might be a candidate for that
>> application?
> Sure.
OK, so:
If someone brought together a single repo with J-Core + toolchain + 
tooling + makefile to effectively get someone to a C or Rust main() and 
memory-mapped RTL modules out-of-the-box, I think this could be part of 
that aforementioned FPGA-accessibility inflection point.
(I did not realize yosys did not support VHDL, so I don't know how 
realistic that is yet)

But that sounds like another forever-project.
If it's something you're working on, though, I'll watch the repos for it 
to appear.

- Andrew

More information about the J-core mailing list