[J-core] Jcore mailing list and tutrle board

BGB cr88192 at gmail.com
Thu Jul 6 14:28:08 EDT 2017

On 7/6/2017 8:11 AM, D. Jeff Dionne wrote:
> On Jul 6, 2017, at 5:58, Rob Landley <rob at landley.net> wrote:
> David,
> Pls see inline.
> J.
>> On 07/04/2017 02:30 PM, David Summers wrote:
>>> On 04/07/17 09:35, Rob Landley wrote:
>>>> On 07/03/2017 02:41 PM, David Summers wrote:
>>>>> Hi Rob,
>> ...
>>>>> Anyway, you probably know the answer to what I was planning to ask
>>>>> anyway. Why on the turtle boards did you fix on the Spartan FPGA? The
>>>>> newer Artix is similar price and newer, e.g.:
> The highest volume product Xilinx ship right now is still S6 in the low cost area, not Artix (I have it on good authority).
> We have a bunch of products using S6 on the commercial side, we don't want A7 right now.
> Once we make a change of tools from ISE to Vivado, we can make a compatible upgrade to either A7 or S7.

seems cool.

>>>>> https://shop.trenz-electronic.de/en/TE0725-03-100-2C-FPGA-Module-with-Xilinx-Artix-7-XC7A100T-2CSG324C-2-x-50-Pin-with-2.54-mm-pitch
>>>>> a 100k gate FPGA for just over a $100.
> And that is another reason why.  $100 is another class of product.  Turtle design goals had a BoM cost of about $50.

I am half wondering here if the current FPGAs could handle a version of 
the ISA with ~5 kbits of register state (~ 160 DWORDs), and a somewhat 
expanded ISA.

     96 dwords for GPRs + system registers;
         existing registers + high words.
     64 dwords for FPRs.
         expanded some to allow 16x128 bit SIMD, also usable as 32 
double registers.
         though, only about 1/2 this space is accessible as 32-bit 
floats for many operations.
             unlike SSE, most of the space is usable as independent 
scalar registers.

ATM, this is about what the 64-bit version of my ISA is looking like.

I have recently been working with trying to get a "working prototype" of 
sorts into working order, but some things are still flexible in the design.

I have generally determined that trying to make the 32-bit ISA's 
memory-footprint smaller by adding instructions is of fairly limited 
effectiveness; so (probably) not a worthwhile tradeoff in the face of 
expanding the complexity of the instruction set (over the existing SH ISA).

it is possible to reduce the number of logical operations (by around 
30%), though most of this is by replacing multiple 16-bit I-forms with 
fewer 32-bit I-forms so the overall memory footprint remains pretty similar.

for the 64-bit ISA, they become a bit more useful, mostly:
     to be able to actually do 64-bit stuff with the way I am currently 
implementing it;
         most 64-bit operations will require dedicated quadword forms, 
ex: "ADD.Q" / etc.
     to mostly avoid a significant expansion of the code footprint.
         as-is, it looks like the footprint expansion from 32-bit to 
64-bit will be fairly modest.
             at-least, if most pointer arithmetic is done with dedicated 
LEA instructions.

some changes (of the 64-bit ISA) from the prior design:
     most of the 16-bit instruction forms behave as they do in 32-bit mode.
         exceptions are LDC.L/STC.L/... which expand to 64-bit forms.
             also MOV.{B/W/L} ops expand to using 64-bit addresses.
         determined that full-scale extension to 64-bit arithmetic would 
be detrimental.
             these is far more 32-bit integer arithmetic than pointer 
arithmetic / etc.
     16-bit MOV.W forms are left as-is.
         most MOV.Q variants will require 32-bit I-forms.
         losing "MOV.W @(PC,disp)" turned out to have more of an adverse 
effect than expected.
     added 16-bit PUSH/POP ops.
         but, dropped a few previously spec'ed ops as they became 
     the number of usable 32-bit GPRs is expanded to 32 (by using the 
low/high halves separately).
         in addition, there are some 3-address arithmetic instructions 
and similar.

the 64-bit ISA still isn't really done yet, and my early testing thus 
far has been in sort of a hybrid mode (some quadword stuff but still 
otherwise using a 32-bit address space).

also, note that 64 bit arithmetic/registers would be accessible by 
32-bit code, but I will probably define doing this as "non-canonical".

but, it goes on... (and hopefully the design is viable).

<snip rest, not much to add>

More information about the J-core mailing list