[J-core] Ho to make a J-core board open sourced properly?

[Rich Felker]

On Wed, Aug 31, 2016 at 11:15:18PM +0200, Daniel V wrote:
> I was thinking of making a open source PCB design with FPGA for making
> computer and CPU, and GPU design, and Hardware development. But I'm
> only prospecting at the moment.
> 
> And I have some questions of going open source as much as possible,
> like engineering tools, and to be able to use that with open source
> software. And what licenses to use for each part in the chain from
> developing hardware firmware and software.

I'm not qualified to answer nearly all of this, but I can tell you in
general that we're at a point in the evolution of this field where
there's still a severe tradeoff between open source purity and
functional capability. People also have very different definitions of
what qualifies as open source hardware; to some people, an open source
PCB design with an ARM cpu on it is "open source hardware"; to others
even a Xilinx FPGA makes it non-open and only something like a
Greenpak (or maybe Lattice) would qualify as open.

SEI is planning to release the Turtle board -- see:

https://twitter.com/jcoreeng/status/730330848306700288

that's form-factor compatible with RPi and oriented towards developers
and hobbyists. I don't have any news on the timeframe for a release
yet but I can tell you the prototypes work very nicely and that it
should provide a good basis for doing further open source hardware
development and gradually eliminating dependency on non-open
components.

> My spontaneous thought was to make a PCB design in kicad. Will that
> do? or is there alternative tools to make a PCB in a open source
> perspective?

There was a nice talk at ELC this year on the different tools
available. The video is probably archived on the conference website.

> What physical interfaces is available for a full open source hardware.
> Can you use is USB and is JTAG suitable? Is there a licence on JTAG?

What need are you trying to fill with the physical interface? The
easiest way to program the FPGA is to have it load from SPI flash. The
Turtle board has on on-board microcontroller for erasing and writing
the flash using a bitstream file on an SD card, meaning you don't need
any cables or software on a host PC to load a new bitstream. In
principle I think you could even make a setup where it loads the
bitstream from an SD card at each boot.

> And for USB there is a licence on hadware? And is there ways to go
> around this with modifications? For example could Linux support a USB
> compatible custom devices, or is that not "legal". Or could you use
> USB standard devices and make a hardware for that in an ASIC? And what
> about JTAG? If it's not possible to use them what can be used?
> 
> If you look at open source hardware accessing hardware they tend to
> use a MCU or a USB to serial converter chip as a front-end. But is
> there a alternative open source alternative? What about MCU:s with
> USB, can they be open source designs?

I believe we're going to have a USB 1.x host core in vhdl, combined
with an external USB 2.0 hub chip on the board, for supporting the
Turtle's USB ports. That's for host/master side. I don't understand
the details but I think USB is actually incompatible with the FPGA in
some major electronic/physical way such that you really need
additional components outside the FPGA to safely attach devices.

There are probably similar issues with implementing a USB slave. Every
board I've seen uses USB to serial converters. Of course if you don't
care about having serial-console-on-USB, you don't even need one.
There are plenty of other ways to interact with the outside world like
LEDs, LCDs, ethernet, legacy RS232 serial ports ...

> One "problem" is what memory to use for a CPU design. If you use
> xilinx parts, would is be preferable to use SRAM on that board? I
> guess that if you use SDRAM that will limit the read speed to make it
> about 4 times slower from SDRAM? or am I mistaken, may it be even
> slower? or do you compensate that with wider SDRAM insterfaces and
> longer pipelines, or cache? Or do you use a FPGA with a hard SDRAM
> block? Or blocking the CPU until the data arrives?

For Xilinx FPGAs you can do "SRAM" on the FPGA itself. The J-core
source also has a DDR controller for (possibly large) external DDR
RAM on the board.

> What about giving it 2 separate SRAM interfaces, and one SDRAM
> interface? In the 90s, cpu-designs started to use modified harvard
> architectures with separate caches for data and programs. If you have
> 2 SRAM, and one SDRAM, you could use SRAM as two separate caches, and
> use the SDRAM as a main memory. Is J-core a modified harvard
> architecture, or is it von-neuman?

I don't know what you want to call it, but it has separate icache and
dcache and you could in theory hook them up to different memory
busses, I guess.

> And when it comes to a "BIOS" do you plant that in the configuration
> memory for the FPGA? Or is there a better way? Is it preferable to be
> able to load that from sd card?

There's a "boot rom" built as part of the bitstream build process.
It's not really a "bios"; it performs some self-tests then loads a
program from the SD card via the SPI bus and jumps to it.

> And is there any open source hardware (with software) to load data to
> and from configuration memory. I'm thinking of being able to change
> the "BIOS" without making a new bit file for the FPGA. And how do you
> do that, should there be a black box proprietary MCU or USB/Serial
> converters on the board?

Reportedly there's a Xilinx tool for replacing the initialized memory
contents without rebuilding the bitstream but I haven't used it. An
alternative approach would be having the initial "boot rom" simply
load the real bootloader from the end of the SPI flash (past the end
of the FPGA bitstream) and pass execution to it, so that you can
modify it independently of the bitstream without special tools.

If you really want to get rid of proprietary MCUs but still have
places in your design where you need a MCU, well, you could always use
a second FPGA with a non-reprogrammable bitstream ROM containing a J2.
Eventually there will be ASICs for this purpose (full J2 and perhaps
also an even-smaller J1, as discussed on this list) but I don't have a
time frame for when that's going to happen.

Rich