[J-core] Sorry for the radio silence.

[Rob Landley]

On 05/11/2017 09:04 PM, BGB wrote:
> On 5/11/2017 11:34 AM, Rob Landley wrote:
>> On 05/10/2017 08:46 AM, Kieran Bingham wrote:
>>> What SoC are you using for the Turtle?
>> We aren't. The brain of the thing is a Xilinx Spartan 6 FPGA. There is
>> no SOC unless you load a bitstream into that FPGA.
>>
>> There is an 8 bit atmel microcontroller that loads the FPGA at from spi
>> flash at power-on, and then switches itself off once the FPGA starts
>> running the bitstream, but it's a brainless little thing running from
>> something like 8k of its own flash. (The other thing it can do is run a
>> little program to reflash the spi from usb if you flip the flash/run
>> switch to flash position; that way the board's a lot harder to brick.)
> 
> nifty.
> 
> I had apparently been under the impression that FPGA's were non-volatile
> things which were flashed similar to an MCU (with the flashing rewiring
> the gates, but with a small/finite number of write-cycles); apparently
> not...

Not the ones we're using.

My understanding is a FPGA is piles of generic circuitry arranged in
repeating "cells" with wires connecting them up in lots of different
ways, and transistors on those wires acting as switches. So you feed in
a bitstream controlling those transistors, indicating which wires should
go through and which ones should stay unplugged, and that's how you
program your FPGA. (I think each bitstream bit controlling one of these
switches has/is its own sram cell?)

And there's wires between cells you can plug into. Some cells have extra
resources like attached sram, some on the edge of the board can plug
wires into special circuits providing things like timing crystals you
can't just whip up from a bunch of NOR gates. Your layout program has to
group stuff physically together and know how long the wires are between
them (because signal propagation delay is a big input into your timing
score, how fast you can clock the result). You can run _out_ of wires
connecting cells together (plenty of circuitry but you can't get a wire
from here to there without going the long way around and screwing up
your timing...)

There's a whole art to this. The great thing abotu VHDL is you can get
the tools to do a whole lot of it for you.

>>> Has the boat set sail already?
>>>
>>> http://www.cnx-software.com/2017/05/10/meet-zynqberry-a-xilinx-zynq-fpga-board-with-raspberry-pi-23-form-factor/
>>>
>> The FPGA in turtle is not a peripheral bolted to the "real" processor,
>> no. All the I/O devices on turtle are routed to the FPGA pins, not to an
>> existing ARM SOC ASIC. (Unless you count the atmel, which can talk to
>> the usb serial and the mmc bus to load/flash the bitstream to spi flash.
>> I'm not sure how martin wired that up because it doesn't come up when
>> the board is running.)
> 
> FWIW: it seems like it would sort-of defeat the point if there were ARM
> cores and various other peripheral HW in-use...

You also need to be able to plug the I/O devices directly into the FPGA
pins, not into some ARM core you're not using.

> I am off doing some of my own stuff, working on a C compiler and
> intending to experiment with some ISA extensions, but am much less
> certain if a significantly extended ISA would be viable for a limited
> transistor budget (or for use on an FPGA).

Inventing your own instruction set in software is easy. Java bytecode,
python bytecode... I believe the spidermonkey and v8 engines use
_different_ bytecodes for mozilla/chrome javascript. Heck, I did my own
bytecode for a bulletin board system I wrote when I was 19. I was so
proud. Then I found out about pascal p-code from 1973 and BCPL's o-code
in 1966 (https://en.wikipedia.org/wiki/O-code).

Doing a good hardware instruction set is a significantly harder problem.
The main reason we haven't finalized and published our proposed 64-bit
instruction set for j-core is until we implement it in hardware (a ways
down the todo list) it's subject to change. (Last year Jeff and I
printed out the instruction set list and worked out that there _is_
enough space to do a 64-bit implementation. I believe Jeff has those
pages, but we could do it again if we need to.)

Rob