[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.
or:
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
unnecessary/redundant.
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