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

[Robert Ou]

On Wed, Aug 31, 2016 at 8:47 PM, D. Jeff Dionne <Jeff at se-instruments.com> wrote:
> 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.

Which exists (https://github.com/m-labs/milkymist/blob/master/cores/softusb/rtl/softusb_navre.v)
and has been used to implement a USB host controller (iirc originally
intended to be OHCI but later changed to a custom interface that only
supports HID).

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