[J-core] 2 CPU:s or nothing

[D. Jeff Dionne]

On Nov 26, 2016, at 3:04 AM, Daniel V <daniel.viksporre at gmail.com> wrote:
> 
> Hi!

Hi Daniel.

> Is Linux capable of low latency stuff? Or do you use a FPGA for that?
> So if you use a ASIC with j-core, do you then need 1ASIC, 1FPGA 1MCU?
> Why is than that ASIC needed, and why is that FPGA needed?

The first j-core chip has SMP CPUs, hardware accelerators for very fast
sample rate signal processing, and a set of DSPs for lower sample rate
signal processing.  Examples of accelerators are GPS correlators and
Delta Sigma decimate engines.  DSPs do things like filters and FFTs.

There isn’t anything like an MCU really, but you might consider the
DSP to fill that role, where all of the X, Y data and P program memories
are on chip SRAM.

> That MCU can then be used to
> patch the holes that Linux has on the real-time side.

Depends on what time scale.  Linux with RTmux is one way (which we intend
to do) and accelerators or DSPs are another (also something we are doing).

> Maybe it's possible to reduce the need of the number of development
> chains to a fewer number, by letting that MCU be built upon a J-core.

You can put a j-core on chip that just uses SRAM, in addition to either
uniprocessor or SMP CPUs for use with the OS / networking side.  This whole
project is designed for sensors, signal processing and networking…

> It's a lot cheaper than to have a separate of the shelf MCU and board
> space for it.

I’m not really sure what the need for an MCU is here.  On Turtle, and on
our Evaluation Boards, we do have an AVR MCU, but it’s purpose is to
provide a USB serial console, give access to JTAG, and allow for
unbrickable reprogramming of the FPGA’s SPI configuration flash.

Our ASIC designs of course need nothing like this.

> If that MCU built upon J-core you could have a masked
> boot ROM in the ASIC, and then be load new programs into RAM. That
> wouldn't be efficient but cheep, and give fewer tool chains, and a lot
> easier to design things with that ASIC later on.

The first ASIC has a mask ROM.  It contains a FATfs bootloader that can
load a second stage bootloader from SDcard.  We use the (much of) the same
ROM in FPGA versions also.  ASICs require BIST, and the production testing
of on chip memories is managed by the j-core running code on the ROM.  Those
ROMs are very space efficient (1T cell).  They also contain the code that
establishes the chain of trust, to allow code image signing, while the key
is in OTP (antifuse) memory.

> Building a ASIC is a bit confusing. Because inefficient things is
> cheep. I'm not promoting bad design. I'm promoting flexibility by
> extending the thought a bit longer, and realize that extended
> capability will save money and time later on and give a longer
> usability of that ASIC, for other loads of projects by making it more
> general. It would cost more for that first application. But is really
> the ASIC the cost split over the number of pieces, than maybe that
> separate MCU should be dumped.

There are development efficiencies that come from modern FPGAs that even
10 years ago one could not get (the FPGA was just too small or too expensive).
Turtle (which you might remember is a Raspberry Pi form factor and I/O
compatible board) uses an FPGA, but also has a USB capable AVR to do all the
things listed above, but once you’ve finished your development, programmed the
SPI flash and no longer need the serial console you can remove it ;^)

We ship customers boards with FPGA versions of j-core, hardware accelerators
and DSPs when the volumes are low, or the development is not finished.  Test
early test often is now possible with hardware because the FPGAs are fast
and large.  Then the designs tested in FPGA, including BTW, very complex signal
processing engines, go to Fab with analog blocks that you (still) can’t do in
FPGA.

Cheers,
J.

> I'm not saying that this is what to do, I'm saying that it's a thought
> that may come in handy for building upon a possible future. It would
> draw people to that platform, instead of away from it, because it does
> not have any practical applications for them.
> 
> Have a nice day
> 
> // Daniel V.
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core