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

[Rob Landley]

On 08/31/2016 10:11 PM, Rich Felker 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.

I wonder why I didn't get the original email? (Do I need to dig through
gmail's spam folder again?)

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

Why would they qualify? (Because they're cheaper? Still a single vendor
per chip, isn't it?)

As far as I know, no FPGA is currently at the state where you can swap
out another vendor's chip and have the same design work out of the box.
This is mostly a toolchain issue though, building a bitstream for Xilinx
vs Lattice is a bit like compiling a C program for x86 vs arm vs sh4.
Unfortunately, bitstreams are still in the Bad Old Days where each
vendor has their own compiler and code builds slightly differently with
each toolchain. We haven't got a gcc equivalent that can parse the same
input and spit out binaries for a bunch of different targets.

> 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

The engineers doing Turtle got pulled off for a bit to put out fires
with another project that went off the rails. Everybody should have time
to breathe again sometime around November, and then we have to do the
second round of prototypes.

My current understanding is we should be in a position to launch the
kickstarter early next year. Whether that means "January" or "April"
depends on how the second round of prototypes goes.

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

If you look at http://j-core.org/news.html there's links to our earlier
efforts at getting nvc to build J1, and then getting it to talk to yosys
(more glue code needed in between to elaborate some stuff).

Yes, I need to bring news.html up to the present. It's on my todo list.

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

No license, but there's some fiddly timing thing getting the debugging
right. (There's half a jtag implementation but the breakpoints were
stopping on the wrong instruction last we checked. I believe the person
who was doing it was a contractor who left, and nobody's been assigned
to finish it up? Not my area...)

If somebody _else_ wants to take a look at the jtag once we've got the
repo up, the OTHER problem is they didn't target openocd, they targeted
some other jtag control thing I've never used, so I didn't try to play
with it myself...

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

I think USB 2.x hardware is clocked faster than this FPGA can go, or
something? And the electrical signals the FPGA is capable of producing
_work_ for 1.1, but violate the spec enough that connecting them
straight to the outside world and calling it USB is impolite.

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

It's a packet protocol! You can route it straight through to QEMU/Kvm
and do all sorts of fun stuff with it! And there's usb gadget stuff
where the kernel produces/consumes packages to fake devices.

I guess the electrical bits are more persnickety about direction and
such. I had the details explained to me once, but don't remember what
the problem was. (Other than "Microsoft was on the standards committee,
and allocated a very large alcohol budget to buy rounds for the group.")

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

I should hook up netconsole when we get the ethernet working again. (I
wonder what it would take to get our bootloader to talk it?)

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

Here are two posts that talk about the dram controller:

  http://lists.j-core.org/pipermail/j-core/2016-April/000038.html

  http://lists.j-core.org/pipermail/j-core/2016-April/000078.html

I need to fish that info out and put it in a proper web page on the
site, but at the time I thought we'd be setting up a wiki. (Again, these
links are in the news.html page.)

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

SRAM tends to come in kilobytes, DRAM in megabytes or gigabytes. Orders
of magnitude problem, running Linux out of SRAM would be EXPENSIVE.

>> And when it comes to a "BIOS" do you plant that in the configuration
>> memory for the FPGA?

In the FPGA it's SRAM with a sort of pump thing that initializes it to
known values at boot time. In an actual ASIC, it should be a proper ROM.

I know there was a post about that, but you'd have some digging to find
it. (I should do a monthly newsletter summarizing list traffic. It's on
the todo list...)

> Or is there a better way? Is it preferable to be
>> able to load that from sd card?

Chicken and egg: you need code to run to do the loading from the 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.

It's something like 8k, written in assembly. It's in the VHDL source
tarball (and is the reason said VHDL source needs a C compiler to
complete the build).

Technically we COULD ship prebuilt binaries of that the way the linux
kernel has _shipped versions of the lex/yacc stuff in kconfig so you
don't need those packages installed as build dependencies... But you'd
still need it if you check out of git (to _produce_) a release tarball.

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

And we're trying to wean our build OFF xilinx-specific tools. J1 should
fit in an ice40 after all. That said, using them for that specific target...

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

But again, at that point you might as well just load Linux. (In theory
it can load an launch any bare metal ELF binary, you could put anything
in there if you're ok with bare-metal programming.)

> If you really want to get rid of proprietary MCUs but still have
> places in your design where you need a MCU,

Marvel Cinematic Universe?

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

J1 discussion linked from the news.html page, and I updated the roadmap
a bit. But yeah, we need so much more...

> Rich

Rob