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

11–20 of 58 posts

Re: Startup to Open-Source Parallel CPU

#11

Post by trsohmers »

vardump wrote: post #4

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?

Our theoretical double precision FLOPs (based on running at 1GHz) per core is 1GFLOP per second, but that is based on doing an add or a multiply. In the case of just doing FMAs, you would be doing 1.5GFLOP. This gives you (theoretical peak) 256 to 384 double precision GFLOPs per chip. Our bandwidth between cores is 16GB/s, while the required bandwidth for doing 1GFLOP is 8GB/s.

Our single precision numbers are actually double that of double precision (compared to a GPU or most other SIMD systems, which have independent FP32 and FP64 FPUs, we have a single combined unit). While our ISA is pure 64 bit, we have packed 32 bit FPU instructions for doing two single precision FLOPs per cycle.

Re: Startup to Open-Source Parallel CPU

#12

Post by asb »

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!

The article was unclear in your open source plans. Will you be opening your hdl, and under what license?

Re: Startup to Open-Source Parallel CPU

#13

Post by trsohmers »

valarauca1 wrote: post #10
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 transla…

At the physical level, each core would have a 128k block that is ascending, but the idea is that our compilers would abstract that away from the programmer, and allocate memory based on what core needs it, and place it in that core's scratchpad, or as close as possible. The DMA capabilities abstract it when actually accessing memory, as it is just a series of (very simple) comparators that get the request to the write block of memory.

Re: Startup to Open-Source Parallel CPU

#14

Post by trsohmers »

asb wrote: post #12
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!

The article was unclear in your open source plans. Will you be opening your hdl, and under what license?

So our current initial plans are to open source the ISA through the Open Compute Project (http://opencompute.org), using their reciprocal license. The HPC group within OCP that I co-lead has plans for HDL and RTL level submissions, but we are not sure what the timeframe or what would be included from REX (yet).

The business case for open sourcing the ISA is that we want others to be making compatible chips. As a small startup with a new architecture, it would be GREAT if others were to make competing chips, as it would only further the architecture and software ecosystem, making it more competitive with the existing market incumbents.

To us, our floating point unit is our "secret sauce", but as an open source enthusiast, I don't want that to be locked up forever. My general idea right now is that we want to be able to tape out our first chip (at least the prototypes for it), and will open source the HDL for the non "secret sauce" parts of it. As we get onto further generations, I do want to open source the full design of our previous chips for free/open use.

Re: Startup to Open-Source Parallel CPU

#15

Post by trsohmers »

trsohmers wrote: post #11
vardump wrote: post #4

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?

Our theoretical double precision FLOPs (based on running at 1GHz) per core is 1GFLOP per second, but that is based on doing an add or a multiply. In the case of just doing FMAs, you would be doing 1.5GFLOP. This gives you (theoretical peak) 256 to 384 double precision GFLOPs per chip. Our bandwidth between cores is 16GB/s, while the required bandwidth for doing 1GFLOP is 8GB/s. Our single precision numbers are actual…

I forgot to add why the separate FP32 and FP64 floating point units are "bad" (from our PoV)... having the separate units just increase complexity, and NVIDIA GPUs, for instance, have 4x the number of FP32 units compared to FP64 units, thus making their single precision numbers (which are what they typically advertise) 4x that of their double precision numbers.

Re: Startup to Open-Source Parallel CPU

#16

Post by TallGuyShort »

My first thought was how this compares to Adapteva's Epiphany architecture (best known for it's use in their crowd-funded Parallela boards), so I was happy to see this project was inspired by that one. Andreas Olofsson from Adapteva has tweeted often about how difficult it is to get funding as a silicon start up, though. I think the statement "it's a tough sell" will prove to be a colossal understatement. But these are impressive kids and it's a great concept - I wish them luck.

Re: Startup to Open-Source Parallel CPU

#17

Post by valarauca1 »

trsohmers wrote: post #13
valarauca1 wrote: post #10

Earlier quoted context omitted.

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 transla…

At the physical level, each core would have a 128k block that is ascending, but the idea is that our compilers would abstract that away from the programmer, and allocate memory based on what core needs it, and place it in that core's scratchpad, or as close as possible. The DMA capabilities abstract it when actually accessing memory, as it is just a series of (very simple) comparators that get the request to the writ…

So the scratchpad isn't so much programmer controlled as just a L1 cache level?

Re: Startup to Open-Source Parallel CPU

#18

Post by trsohmers »

valarauca1 wrote: post #17
trsohmers wrote: post #13

Earlier quoted context omitted.

At the physical level, each core would have a 128k block that is ascending, but the idea is that our compilers would abstract that away from the programmer, and allocate memory based on what core needs it, and place it in that core's scratchpad, or as close as possible. The DMA capabilities abstract it when actually accessing memory, as it is just a series of (very simple) comparators that get the request to the writ…

So the scratchpad isn't so much programmer controlled as just a L1 cache level?

I would not call it a cache as it is: 1)Physically addressed 2)Has no complex control logic (TLB, CAMs, additional flags) 3)Us not just simply replicating something higher up in a memory hierarchy

A programmer will have full access to be able to handle memory however they want, but we want to be able to build out the tools to allow for a programmer to treat it similarly to an L1 cache (that is part of a shared memory space... that has different access times)

Re: Startup to Open-Source Parallel CPU

#19

Post by trsohmers »

TallGuyShort wrote: post #16

My first thought was how this compares to Adapteva's Epiphany architecture (best known for it's use in their crowd-funded Parallela boards), so I was happy to see this project was inspired by that one. Andreas Olofsson from Adapteva has tweeted often about how difficult it is to get funding as a silicon start up, though. I think the statement "it's a tough sell" will prove to be a colossal understatement. But these a…

I was working on the Parallela boards for a long time... but there are fundamental flaws in the architecture (missing instructions, it is only 32 bit, not IEEE754-2008 compliant, etc) that makes the Epiphany architecture not really suitable for the markets we are trying to address. When we decided to go out and make our own, we knew there was going to be a lot of difficulties, but the idea is that if we are going to do a startup and give it our all, why not try to do something big?

The fact that we are using mostly open source tools for our development (such as Chisel: chisel.eecs.berkeley.edu), our development time has decreased and productivity has had a huge boost compared to if we were just writing in Verilog. We also made the decision to not use off the shelf IP, which while difficult to verify, we think we make a much better system. Compare this to the Epiphany implementations, which while having a custom ISA and basic core components, used off the shelf ARM interconnect, off the shelf ARM memory compiler, and many other things that were used to minimize development time and verification. While this is a bit more difficult upfront, since we are keeping our components very simple, our verification is no where near as complex as a "normal" processor. Plus we don't have to pay $500k-$1m+ in upfront licensing fees.

Re: Startup to Open-Source Parallel CPU

#20

Post by trsohmers »

trsohmers wrote: post #8
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 ha…

I realized I didn't fully answer the chip-to-chip interconnect questions... it is an extremely simple parallel interface (that I would not even call a "bus", as that is assuming it has a lot more control logic than it has). Instead of having a full serdes per lane, our solution is to use a very simple latch and buffer, along with PLLs on each chip to have a MUCH (50-70%) smaller and more power effecient point-to-point connection between chips. As such, it is not packet based, and we are really just focusing on moving a 64 bit word per cycle.
Post reply on HN