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

21–30 of 58 posts

Re: Startup to Open-Source Parallel CPU

#21

Post by valarauca1 »

trsohmers wrote: post #18
valarauca1 wrote: post #17

Earlier quoted context omitted.

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…

Interesting. I look forward to playing around with one.

Re: Startup to Open-Source Parallel CPU

#22

Post by wglb »

trsohmers wrote: post #18
valarauca1 wrote: post #17

Earlier quoted context omitted.

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…

So the scratchpad memory contains instructions as well as data?

Re: Startup to Open-Source Parallel CPU

#23

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.

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.

Re: Startup to Open-Source Parallel CPU

#24

Post by trsohmers »

trsohmers wrote: post #18
valarauca1 wrote: post #17

Earlier quoted context omitted.

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…

@wglb: That is the plan for now. An instruction cache is possible, but we don't see the need to add extra complexity.

Re: Startup to Open-Source Parallel CPU

#25

Post by asb »

trsohmers wrote: post #14
asb wrote: post #12

Earlier quoted context omitted.

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

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?

Re: Startup to Open-Source Parallel CPU

#28

Post by lavomme »

First of all, good luck for you guys.

I've worked in a start-up company similar to your company.

We developed a 256-cores RISC processor, only shared memory was used between all the cores instead of a mash-up of a memory block for each core and DMA for transactions.

How do you intend to synchronize work between the different cores? How a compiler will abstract away the memory synchronizations? Which programming language is going to be used? So many questions as this is such a complex area in computing...

From my personal experience of over 5 years developing such chip in a start-up company, the cost of production will probably be a huge obstacle. Good luck!

Re: Startup to Open-Source Parallel CPU

#29

Post by nkurz »

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!

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.

Re: Startup to Open-Source Parallel CPU

#30

Post by trsohmers »

asb wrote: post #25
trsohmers wrote: post #14

Earlier quoted context omitted.

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

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?

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.

Post reply on HN