Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup to Open-Source Parallel CPU

eetimes.com

Post reply on HN
Print view View original

1–10 of 58 posts

Re: Startup to Open-Source Parallel CPU

#3

Post by alain94040 »

trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

Impressive for your age. But how is this any different from the millions of identical proposals that never got anywhere? Packing plenty of alus with some sort of basic network hasn't really worked out in real life. The first block diagram in the article is so basic it's concerning.

Apologies for being critical, I wish you the best.

Re: Startup to Open-Source Parallel CPU

#4

Post by vardump »

I wonder what kind of penalties there are for transmitting data to neighboring nodes. Same for receiving. If every node does for example receives data from a neighboring node, does a single fused multiply-add and transmits the result to a neighboring node, how many FLOPS you get out of the whole thing?

How big chunks of computation you need to do in a node for this to be effective?

Re: Startup to Open-Source Parallel CPU

#6

Post by sargun »

Does anyone know what the actual CPUs are? It mentions it has 64 registers? My guess is ARM / MIPS, based upon: http://en.wikipedia.org/wiki/Processor_register

How much scratch memory is there? Is it SRAM?

Are they licensing anyone's IP for the interconnect, or CPU? What's the bandwidth of the interconnect? Is is packet-oriented? How does fair-routing work?

Re: Startup to Open-Source Parallel CPU

#7

Post by trsohmers »

alain94040 wrote: post #3
trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

Impressive for your age. But how is this any different from the millions of identical proposals that never got anywhere? Packing plenty of alus with some sort of basic network hasn't really worked out in real life. The first block diagram in the article is so basic it's concerning. Apologies for being critical, I wish you the best.

The article is incorrect in saying that the (very simplistic...it's supposed to just show the basic components per core, not how it is actually functioning) diagram for a single core is the whole chip... our chip design has 256 of those cores (So in total, 256 64 bit ALUs and 256 64 bit FPUs). We have a custom mesh network that allows for atomic operations on from any core to any adjacent core, and DMA operations that allow for a read or write to any core's local scratchpad memory from any other scratchpad memory.

In comparison to other architectures, we have chose to stick to RISC, instead of some crazy VLIW or very long pipeline scheme. In doing this, we limit compiler complexity while still having very simple/efficient core design, and thus hopefully keeping every core's pipeline full and without hazards. The idea is that we just want to have a bunch of very simple and focused SPMD cores, so that we can have a MIMD/MPMD chip.

We are currently fixing the bugs on our single core FPGA demo, and hope to have our full 256 core cycle accurate simulator done by ~January/February. We want to release that (and our currently very early compilers) to the public ASAP.

Re: Startup to Open-Source Parallel CPU

#8

Post by trsohmers »

sargun wrote: post #6

Does anyone know what the actual CPUs are? It mentions it has 64 registers? My guess is ARM / MIPS, based upon: http://en.wikipedia.org/wiki/Processor_register How much scratch memory is there? Is it SRAM? Are they licensing anyone's IP for the interconnect, or CPU? What's the bandwidth of the interconnect? Is is packet-oriented? How does fair-routing work?

Custom ISA that we have developed... we developed it in parallel to RISCV (before they released their public 2.0 ISA), but we have diverged a bit... we are a static 64 bit ISA, have no options to have VLIW expandability, our FPU (and thus its instructions) are able to do two single precision IEEE754-2008 FLOPs per cycle, and one double precision per cycle. We have also added a set of DMA instructions.

We currently have 128KByte dual-ported SRAM per core (which is physically part of the core, and not a giant array somewhere else on die). It has single cycle latency to the core's registers and to the Network on Chip router.

The on chip mesh network is custom 128 bit wide going core to core. The router can do a read or write to SRAM per cycle AND allows a passthrough to another core in the same cycle.

Our chip-to-chip interconnect is a custom 64 bit (72 lane) parallel interface allowing 48GB/s. There are two of these (unidirectional) interfaces per side, giving you a total of 8 of these interfaces per chip.

Re: Startup to Open-Source Parallel CPU

#9

Post by trsohmers »

wglb wrote: post #5
trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

This looks pretty exciting. How much is the scratchpad memory in each of the processors?

128K per core, so 32MB per chip. This is really just a fabrication/size limitation... we are planning for 28nm right now, and don't want our memory to use (too much) more power than our actual compute logic ;)

If we can go to 14/16nm in the future, we are planning 512 and 1024 core versions with different amounts of memory depending on if you are memory or compute bound.

Re: Startup to Open-Source Parallel CPU

#10

Post by valarauca1 »

trsohmers wrote: post #2

I'm the founder and CEO of REX... Check out our website for a brief overview ( http://rexcomputing.com ) and feel free to ask questions here!

This tripped me up a bit

>Local scratchpad memories are physically addressed as part of a flat global address space.

So from the programmers perspective each core will have a block of the address space, I.E.: 0-255, 256-511, 512-767, 768-1023 etc.?

Or is there address translation between units? Or if a thread is just built to arbitrarily execute on a unit, it'll have to pre-process its position for name space translation?

Also is there a memory locking in local scratchpad? (I maybe reaching).

Post reply on HN