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

[D. Jeff Dionne]

On Sep 1, 2016, at 12:11 PM, Rich Felker <dalias at libc.org> wrote:
> 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.

I think this is exactly correct.  And as I have mentioned before, Yosys
and QFlow are another level of open when you move to ASIC, but I’m not
sure anyone has actually taped out (sent for fabrication, essentially)
anything or significant complexity using that flow yet, especially since
it appears that ATPG (basically, automatic insertion of production test
logic) isn’t quite there yet.

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

Yup.  IMHO, Turtle is an important step, there are a lot of little
boards (like Numato Mimas) with a small FPGA and DDR memory, but
nothing besides Turtle is available that is not ‘just’ an FPGA dev
board.  Turtle is supposed to be proof that you can do something as
practical as an Pi2, and you can do it ‘open’ (see above ;).

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

Turtle has an Atmel AVR USB (yes, the code is open) as a ‘boot monitor’.
It seems to me that we could have chosen a Lattice ICE40 FPGA for that also,
since it’s highly likely that we could fit a USB Function Controller and
a small CPU in one, iff we could convince ourselves that the ICE40 can be
electrically compatible enough with the USB standard… it certainly doesn’t
have a proper transceiver on it, so it might be flaky.  But the AVR as a boot
monitor and console USB-UART is for the moment a good tradeoff, we think.

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

The problem is the FPGA can generate signalling that a host or function
will accept (that has been shown), but it doesn’t meet the specs and
therefore cannot, isn’t ’safe’ to, or at best should not, be exposed to
the world outside a board that aims at general use.  The solution we
came up with is to use a hub chip to buffer the FPGA.  That obviates
the need for a USB Phy chip, which BTW costs many times what a hub
chip (with many Phy inside) does, because of economies of scale (no one
uses a stand alone Phy chip in quantity).

> There are probably similar issues with implementing a USB slave.

I am always reminded by USB people that it’s called a USB Function ;)
but yes, there are, and they are even slightly worse.  The reason is
USB mandates low power modes, where the Function must behave in certain
ways (electrically) if it is put to sleep.  Turtle doesn’t meet all of
that -even with- the AVR on board.

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

That is implemented of course in the AVR on Turtle, but as I said CDC
protocol could be done in an ICE40 also…

> There are plenty of other ways to interact with the outside world like
> LEDs, LCDs, ethernet, legacy RS232 serial ports …

Yup.

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

Yes, I call it I and D cache, (SH parlance is/was Instruction and Operand)
and we do call J-Core modified Harvard, with separate I and D busses, but
of course to appear Von Neuman to the programmer, those busses immediately
go into a mux to present a single bus to the memory system so that there
is a unified address space.

>> 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 also a GDB stub, which was really useful during bring up, but hasn’t
been used by anyone for quite some time since Linux runs ;)

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

Like an ICE40...

> with a non-reprogrammable bitstream ROM containing a J2.

Or an open version of AVR.

> 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
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core