Comment by trsohmers | Hacker News Reader

Comment by trsohmers | Hacker News Reader

Parent Full thread

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.

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.

I asked this previously without seeing that you had answered it here. So you're claiming to have a parallel interface without a SERDES running at 64-bits at 6 Gb/s? How are you maintaining bit alignment between lanes? Do you have any in-line signal conditioning or anything (CTLE, DFE, etc.)? Parallel interfaces are rarely run faster than 1 Gb/s, so 6 Gb/s sounds unlikely.

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

Going over 50 cm of Twinax is great and all, but that's the ideal environment. When you guys put 16 of these things on a board, routing that PCB and getting good signal integrity is not going to be fun, even after you throw in pre-emphasis and so on.

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.

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.

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.

Reply on news.ycombinator.com