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

51–58 of 58 posts

Re: Startup to Open-Source Parallel CPU

#51

Post by ajb »

trsohmers wrote: post #39
mechagodzilla wrote: post #35

Earlier quoted context omitted.

Can you provide some more details on your parallel interface? As an ASIC designer, these numbers sound extremely fishy for a non-serdes interface. A 128-bit parallel interface (which is a lot of pins, especially if you need 8 links) would need to be running at 3 GHz, for instance, to hit that. Is it differential/single-ended? Source-synchronous? How big of a package are you planning?

(Copied from another comment on this page): Relevant paper (by Intel Research, actually)... there are quite a few differences (we are keeping it a lot simpler on the tx and rx ends, but that is some of our secret sauce... I can talk about it offline if you are really interested) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=648778... .

FYI, That link doesn't work, but the one you posted here: https://news.ycombinator.com/item?id=8659653 does.

Re: Startup to Open-Source Parallel CPU

#52

Post by trsohmers »

mechagodzilla wrote: post #49
trsohmers wrote: post #38

Earlier quoted context omitted.

Relevant paper (by Intel Research, actually)... there are quite a few differences (we are keeping it a lot simpler on the tx and rx ends, but that is some of our secret sauce... I can talk about it offline if you are really interested) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=648778...

Getting anything approximating Intel's work, assuming you are rolling all your own IP, is pretty ambitious (and probably a good deal more work than your Core design). Even at only 6 Gbit/s (faster than PCIe Gen2, btw). Just curious - have you ever taped out a chip on a modern process before?

We aren't trying to reach their 128GB/s number as listed in that paper, only 48GB/s... in addition to our design being much simpler than that. Our design is having each pin is simply a buffer and a latch that is synchronized with all the other pins part of the interface by a PLL... much easier to implement and run than a serializer for even just a single pin.

I myself have not taped out something on a modern process, but have advisors who have. My co founder and I do have nanofab experience, so we do understand the physical complexities of fabrication first hand.

Re: Startup to Open-Source Parallel CPU

#53

Post by mechagodzilla »

trsohmers wrote: post #52
mechagodzilla wrote: post #49

Earlier quoted context omitted.

Getting anything approximating Intel's work, assuming you are rolling all your own IP, is pretty ambitious (and probably a good deal more work than your Core design). Even at only 6 Gbit/s (faster than PCIe Gen2, btw). Just curious - have you ever taped out a chip on a modern process before?

We aren't trying to reach their 128GB/s number as listed in that paper, only 48GB/s... in addition to our design being much simpler than that. Our design is having each pin is simply a buffer and a latch that is synchronized with all the other pins part of the interface by a PLL... much easier to implement and run than a serializer for even just a single pin. I myself have not taped out something on a modern process,…

Ah, so the idea is to have 64 parallel bits coming in at 6 Gbits/s, along with a slower clock that you multiply up to 6 GHz and use to sample the inputs? That will be quite tricky to get working 1) without any analog signal conditioning on the inputs (or outputs), and 2) without inter-bit skew making it impossible to meet timing on your inputs. Best of luck to you, but the interface alone sounds likely to be problematic.

Re: Startup to Open-Source Parallel CPU

#54

Post by trsohmers »

mechagodzilla wrote: post #53
trsohmers wrote: post #52

Earlier quoted context omitted.

We aren't trying to reach their 128GB/s number as listed in that paper, only 48GB/s... in addition to our design being much simpler than that. Our design is having each pin is simply a buffer and a latch that is synchronized with all the other pins part of the interface by a PLL... much easier to implement and run than a serializer for even just a single pin. I myself have not taped out something on a modern process,…

Ah, so the idea is to have 64 parallel bits coming in at 6 Gbits/s, along with a slower clock that you multiply up to 6 GHz and use to sample the inputs? That will be quite tricky to get working 1) without any analog signal conditioning on the inputs (or outputs), and 2) without inter-bit skew making it impossible to meet timing on your inputs. Best of luck to you, but the interface alone sounds likely to be problema…

That's the basic idea, but we can run it at 3GHz if we do DDR, or 1.5GHz doing QDR. There is some extra magic there which I don't want to talk publicly about just yet ;)

The biggest problem (even with our solutions for skew and crosstalk) is just the number of pins/traces on the board, but that's not unsolvable... nothing a ~10 layer PCB can't solve.

Re: Startup to Open-Source Parallel CPU

#55

Post by vardump »

trsohmers wrote: post #47
vardump wrote: post #33

Earlier quoted context omitted.

So how many I can do if for each FMA I also receive 16 bytes of data from a neighboring node and send 16 bytes of data to a neighboring node? Or is the data transfer free, is the neighboring node memory mapped? If so, how does synchronization work? Edit: didn't notice same was asked before too. Regardless, how many FMAs can be executed in the scenario I gave, also sending 16 bytes and receiving 16 bytes for each FMA?

The superscalar design means Load/Store unit can operate independently from FMA and DMA units, i.e. FMA operation on register operands will not interfere with other operations elsewhere on the chip. Synchronization should be handled in a dataflow-driven program design. Any sort of mutex/semaphore/etc. will have to be software defined or interrupt-driven. In regards to neighboring node being memory mapped... are you a…

I guess this is one of those cases where you just need to get your hands dirty to really understand it.

Can you do reasonably efficient [arbitrary size] fixed point arithmetic on your hardware? Do you have 64-bit add with carry and 64-bit multiply with 128 bit results? I'm interested in 64.64 and 128.128. Needed operations are add, sub and multiply.

I think compute grids like these could very well be an important part of computing in the future, maybe even the most important part. Ever since when I first saw an article about transputer. Grids or VLIWs, sadly software is always the pain point. I wish you luck, please get this working and right.

Re: Startup to Open-Source Parallel CPU

#56

Post by m_mueller »

trsohmers wrote: post #34
nkurz wrote: post #31

Unlike GPUs and other SIMD accelerators, Neo's MIMD processor design leverages independent program counters and instruction registers in each core to allow different operations to be performed in parallel on separate pieces of data. [1] Other than the grid interconnect, how does the architecture differ from Xeon Phi? In particular, what allows it to get such dramatically higher power efficiency? I'd have guessed that…

Thanks for that... didn't notice that we had a repeated section (I just updated it with the proper text for that section) As for comparison to the Phi... it is the fact that our actual core size (and thus the whole chip) is MUCH smaller. The Phi's cores are actually based on the original Pentium architecture (they are just downsized P54Cs) with added AVX instructions. Contrary to popular belief, they are not full x86…

Intel's insistence on x86 and dragging old designs around just isn't sustainable in the long run, especially once silicon gets to its absolute physical limits and Intel looses its traditional process technology advantage for a while (until a new material is introduced). Knight's Landing may be a temporary reverse to the killer micro order, but I give a higher chance to IBM+NVIDIA winning the next round, maybe followed by an architecture like yours.

Re: Startup to Open-Source Parallel CPU

#57

Post by sliekasbekelniu »

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!

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

Re: Startup to Open-Source Parallel CPU

#58

Post by solobratsche »

Also wish you good luck and recommend change focus: First figure out, what kind of real world problems this architecture can handle and how to do it best. The architecture will perform very well, if the number of operations, which can do done on a set of data fitting into the scratchpad memory is large, so that communication overhead is small or if the problem can be mapped to the grid in a way that they only require communication with the neighbours. However I would assume that typical real world big data problems don't fulfill these requirements and problems fulfilling them also run well on classical architectures. As soon as you start to need a lot of data transfer, only the cores close to the border of the grid will be able to work, as they get data, the ones at the border are busy with forwarding data to the memory and the innermost just wait ... Therefore before investing a lot of effort, money and time into a hardware, which many others also do in very similar ways and ask the community to find out, how to use it, spend the energy in innovative ideas to actually efficiently use such architectures. I.e. languages, profiling and debug tools, ... That's where the real innovation is needed and where there is a lot of room for improvement. And if you want to stay with hardware it is probably much easier to convince investors, if you can show in a simulation of FPGA prototype that 2 or 3 real world applications showing a very bad performance on classical machines can achieve a substantive boost on your architecture ...
Post reply on HN