[J-core] Sorry for the radio silence.

[BGB]

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


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


> Sorry, I'm going "didn't I just write up a lot post about this in the
> context of somebody asking hardware security questions?" But that was on
> another list:
>
> http://lists.svlug.org/archives/svlug/2017-May/062399.html

yep.


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

for testing, I am probably going to evaluate between the extensions and 
what is possible with a more constrained ISA (more like the normal SH 
2/4 ISA). evaluations would likely be via a mix of code-density and 
relative performance-per-operation-word (rather than absolute 
performance; goal mostly to try to increase competitiveness).

also can't say for certain how many of the ideas here are 'safe' though...

for right now, mostly focusing on making the basic ISA work well though 
(primarily focusing on an SH4 subset; trying to generate passable code; 
...).

the C variant should be basically compatible with most typical C code, 
but isn't really aiming for universal coverage (some obscure/legacy 
features may be omitted, ...)


another hypothetical idea is for possibly asymmetric systems, where some 
more advanced features (32-bit extended I-forms, or the use of possible 
SIMD operations, or FPU) may only be available on certain cores (say, 
with others as simpler integer-only cores or similar), with the OS 
scheduler expected to deal with it (by rescheduling faulted threads onto 
cores which have the needed ISA features).

this could be mostly invisible to software; apart from multiple threads 
trying to use advanced features all being forced into running on a 
single core; or experiencing a performance hit if the operations need to 
be emulated (no cores supporting the features exist; but the kernel 
includes the logic for emulating them).