5 ms·

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

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

alain94040 12y ago
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.
- trsohmers 12y ago
  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.
- trsohmers 12y ago
  I should also point out that it isn't just a bunch of ALUs or FPUs connected by a network... each core has it's own full execution logic, making each core a full 5-stage superscalar RISC core that can independently operate on its own instruction and own piece of data.
wglb 12y ago
This looks pretty exciting. How much is the scratchpad memory in each of the processors?
- trsohmers 12y ago
  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.
valarauca1 12y ago
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).
- trsohmers 12y ago
  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.
  - valarauca1 12y ago
    So the scratchpad isn't so much programmer controlled as just a L1 cache level?
    - trsohmers 12y ago
      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)
      - valarauca1 12y ago
        Interesting. I look forward to playing around with one.
asb 12y ago
The article was unclear in your open source plans. Will you be opening your hdl, and under what license?
- trsohmers 12y ago
  So our current initial plans are to open source the ISA through the Open Compute Project (http://opencompute.org 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.
  - asb 12y ago
    Thanks for the answer. Another quick question. One of the limitations of parallela is the offchip memory bandwidth. Will you be integrating a third party phy?
    - trsohmers 12y ago
      Our chip-to-chip bandwidth is currently 48GB/s per parallel interface, and we have 8 of those per chip (2 per side), giving us an aggregate bandwidth of 384GB/s. The Epiphany 4's interfaces are 1.5GB/s serial (12.5Gb serdes), and there are 4 of those per chip, giving you an aggregate bandwidth of 6GB/s. If you can spend a bit more power (or wait for 14/16nm process), we think it is possible to double that to 96GB/s per interface. Using some more exotic methods (which are purely in an idea stage right now, and not tested, are are a couple years away at best), we think it is possible to get that up to 128GB/s per interface.
nkurz 12y ago
Is there a plain text version of the overview on the page you linked? The current version is very pretty as a homepage, but if there was a short white-paper available it would help the put the focus on the information. Personally, I found that the slide-ins and wobbly text made it difficult to keep my place. I tried Readability, but it didn't do well on it. Scrolling to the bottom to let the glitz run its course, and then scrolling back up to the top to read helped in the end.
fpp 12y ago
Very impressive. How does this compare to other multi-core processors / architectures e.g. epiphany http://www.adapteva.com/introduction/ http://www.adapteva.com/introduction/
- trsohmers 12y ago
  There are a lot, and I would recommend reading through this page... the basics on Epiphany (and the same can be said about most others) is the fact that we designed from the start to have a very high memory/IO bandwidth (both on and off chip), stuck to RISC, and focused on floating point (one of the few architectures in this area being fully IEEE compliant with this high of a performance per watt ratio).
sliekasbekelniu 12y ago
Hi, trsohmers, have you ever heard of Epiphany[1] ? They claim to achieve 70 GFLOPS/WATT. Also the processor seems to be fairly fast and they manage to put 4096 cores on a chip. Though no activity in recent time. Maybe you could find some collaboration points with them.. [1] http://www.adapteva.com/epiphany-multicore-intellectual-property/ http://www.adapteva.com/epiphany-multicore-intellectual-prop...

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

alain94040 12y ago

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.

trsohmers 12y ago
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.
trsohmers 12y ago
I should also point out that it isn't just a bunch of ALUs or FPUs connected by a network... each core has it's own full execution logic, making each core a full 5-stage superscalar RISC core that can independently operate on its own instruction and own piece of data.

wglb 12y ago

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

trsohmers 12y ago
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.

valarauca1 12y ago

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

trsohmers 12y ago
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.
- valarauca1 12y ago
  So the scratchpad isn't so much programmer controlled as just a L1 cache level?
  - trsohmers 12y ago
    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)
    - valarauca1 12y ago
      Interesting. I look forward to playing around with one.

asb 12y ago

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

trsohmers 12y ago
So our current initial plans are to open source the ISA through the Open Compute Project (http://opencompute.org 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.
- asb 12y ago
  Thanks for the answer. Another quick question. One of the limitations of parallela is the offchip memory bandwidth. Will you be integrating a third party phy?
  - trsohmers 12y ago
    Our chip-to-chip bandwidth is currently 48GB/s per parallel interface, and we have 8 of those per chip (2 per side), giving us an aggregate bandwidth of 384GB/s. The Epiphany 4's interfaces are 1.5GB/s serial (12.5Gb serdes), and there are 4 of those per chip, giving you an aggregate bandwidth of 6GB/s. If you can spend a bit more power (or wait for 14/16nm process), we think it is possible to double that to 96GB/s per interface. Using some more exotic methods (which are purely in an idea stage right now, and not tested, are are a couple years away at best), we think it is possible to get that up to 128GB/s per interface.

nkurz 12y ago

Is there a plain text version of the overview on the page you linked? The current version is very pretty as a homepage, but if there was a short white-paper available it would help the put the focus on the information. Personally, I found that the slide-ins and wobbly text made it difficult to keep my place. I tried Readability, but it didn't do well on it. Scrolling to the bottom to let the glitz run its course, and then scrolling back up to the top to read helped in the end.

fpp 12y ago

Very impressive. How does this compare to other multi-core processors / architectures e.g. epiphany http://www.adapteva.com/introduction/ http://www.adapteva.com/introduction/

trsohmers 12y ago
There are a lot, and I would recommend reading through this page... the basics on Epiphany (and the same can be said about most others) is the fact that we designed from the start to have a very high memory/IO bandwidth (both on and off chip), stuck to RISC, and focused on floating point (one of the few architectures in this area being fully IEEE compliant with this high of a performance per watt ratio).

sliekasbekelniu 12y ago

Hi, trsohmers, have you ever heard of Epiphany[1] ? They claim to achieve 70 GFLOPS/WATT. Also the processor seems to be fairly fast and they manage to put 4096 cores on a chip. Though no activity in recent time. Maybe you could find some collaboration points with them.. [1] http://www.adapteva.com/epiphany-multicore-intellectual-property/ http://www.adapteva.com/epiphany-multicore-intellectual-prop...