3 ms·

Boy, do I have a new processor architecture for you. For the past 3 years my company (REX Computing), has been working on a new architecture that not only cover

Boy, do I have a new processor architecture for you. For the past 3 years my company (REX Computing), has been working on a new architecture that not only covers both of your points, but removes hardware managed caching entirely and replaces it with software managed (physically addressed) scratchpad memory. By removing all of the unnecessary logic (MMU, TLB, everything required for virtual addressing, prefetching, coherency, etc) associated with the onchip memory system, we can fit more memory on the chip itself, have lower latency to that memory, and use a lot less power. As we fully expose the memory system to our software tools, we can make very good decisions at compile time that replicate most of the features you get in having a hardware managed caching system. We have silicon back, and are now working with early customers in showing a 10 to 25x energy efficiency improvement for high performance workloads. I gave a talk at Stanford last week that covers the hardware architecture and shows off our development hardware: https://www.youtube.com/watch?v=ki6jVXZM2XU https://www.youtube.com/watch?v=ki6jVXZM2XU

i336_ 10y ago
Wow. (Not op) Definitely watching the video later when I have time. Thoughts from my initial impression: 1. Please put benchmarks up on HN when you can :) 2. Would be awesome if you could get this into the hands of low level kernel developers who can tinker with this and see what Linux is like on it - if it's capable of doing that much? (Need to watch the video!) 3. Conservativism FTW (IMO) when thinking about offers [that come in after you've done (1) :P]
- trsohmers 10y ago
  1: Around the 30:40 mark in the video I transition to the live hardware demo, where I learned to never do live demos. While it did not work there in person, I do show pictures from it working earlier in the day along with the results from our 1024-point in place FFT assembly test. It was written and tested Monday and Tuesday of last week (finished the night before the presentation), so it is not fully optimized, but we are getting a very good 25 double precision GFLOPs/watt. As a comparison, Intel and NVIDIA's advertised FP64 numbers are around 8 to 12 GFLOPs/watt while they are on a more advanced process node (They are on 14/16nm, while our test silicon was on 28nm). We're in the process of getting cross platform benchmarks (HPL, HPCG, FFTW, Coremark, etc) up and running, but I'm hoping we'll be posting results shortly. 2. Since Linux 4.2, there has been a mainline port for STM32 which does not have a MMU, so porting linux is technically possible, though not on our priority list. Something like uCLinux would probably be easier, but not as useful. I have no doubt our cores would be able to handle it, it is just that our current customers already expect their software to be running on bare metal.
  - orbifold 10y ago
    I didn't watch the talk in full, so forgive me if you addressed this somewhere in the Q&A: What are the differences between your architecture and the Epiphany chips? As far as I can tell they have approximately the same amount of local scratch pad memory and also a 2D mesh routing infrastructure and general overall design philosophy, one major difference seems to be the Serdes design that you have. Edit: Ah ok, one major difference seems to be that you have quad-issue VLIW as opposed to RISC and apparently you are 10x faster than Epiphany, that is really impressive.
    - trsohmers 10y ago
      On your edit: RISC and VLIW are not mutually exclusive. I would say we are a RISC architecture (Load/store based/everything happens on registers, fixed instruction word size, shallow pipeline) that happens to have a much simpler instruction decoder & higher instruction level parallelism since our compiler guarantees that the instruction bundle (the 64 bit Very Long Instruction Word containing 4 "syllables" of instructions itself) will only give instructions that will not conflict with anything it is given with or in the pipeline. Other than we are faster (20% higher clock plus 2x higher IPC) and more efficient (Epiphany is single precision only, where we are twice as efficient as them, we also support FP64), there are three quick points: 1. We actually have double the local scratchpad of Epiphany per core, and our SPM banking and register port scheme actually enables us to operate all four functional units within a core simultaneously, while also having data go in and out of the core on the Network on Chip. With Epiphany, you are very limited in what instructions can run together primarily due to port conflicts... the biggest difficulty is that you can't do any sort of control instructions with anything else. 2. As far as the Network on Chip goes, we are able to guarantee all latencies through a strict deterministic static priority routing scheme. Epiphany had 3 levels of it's Network on Chip, one for stores, one for read requests (8x slower than stores), and one for off chip communications. We have a (patent pending) way of simplifying all of this greatly while reducing latency and having greater bit efficiency. 3. Off chip memory bandwidth is extremely important to us. Even on our test chip, we have 4x higher bandwidth than the Epiphany IV, plus lower latency... our chip to chip and memory interface also uses the exact same protocol as our NoC, simplifying things even further. There are a handful of smaller things, though my biggest gripe with Epiphany has always been the lack of bandwidth both on and especially off chip. If you are targeting DSP and similar applications like both Epiphany and we are, you really really need to have the ability to saturate your networks and match compute capabilities with it.
nemo1618 10y ago
This is so cool to hear. I've long been holding out hope that we won't be trapped in the current CPU paradigm forever. Thank you for the work you're doing.

i336_ 10y ago

Wow. (Not op) Definitely watching the video later when I have time. Thoughts from my initial impression: 1. Please put benchmarks up on HN when you can :) 2. Would be awesome if you could get this into the hands of low level kernel developers who can tinker with this and see what Linux is like on it - if it's capable of doing that much? (Need to watch the video!) 3. Conservativism FTW (IMO) when thinking about offers [that come in after you've done (1) :P]

trsohmers 10y ago
1: Around the 30:40 mark in the video I transition to the live hardware demo, where I learned to never do live demos. While it did not work there in person, I do show pictures from it working earlier in the day along with the results from our 1024-point in place FFT assembly test. It was written and tested Monday and Tuesday of last week (finished the night before the presentation), so it is not fully optimized, but we are getting a very good 25 double precision GFLOPs/watt. As a comparison, Intel and NVIDIA's advertised FP64 numbers are around 8 to 12 GFLOPs/watt while they are on a more advanced process node (They are on 14/16nm, while our test silicon was on 28nm). We're in the process of getting cross platform benchmarks (HPL, HPCG, FFTW, Coremark, etc) up and running, but I'm hoping we'll be posting results shortly. 2. Since Linux 4.2, there has been a mainline port for STM32 which does not have a MMU, so porting linux is technically possible, though not on our priority list. Something like uCLinux would probably be easier, but not as useful. I have no doubt our cores would be able to handle it, it is just that our current customers already expect their software to be running on bare metal.
- orbifold 10y ago
  I didn't watch the talk in full, so forgive me if you addressed this somewhere in the Q&A: What are the differences between your architecture and the Epiphany chips? As far as I can tell they have approximately the same amount of local scratch pad memory and also a 2D mesh routing infrastructure and general overall design philosophy, one major difference seems to be the Serdes design that you have. Edit: Ah ok, one major difference seems to be that you have quad-issue VLIW as opposed to RISC and apparently you are 10x faster than Epiphany, that is really impressive.
  - trsohmers 10y ago
    On your edit: RISC and VLIW are not mutually exclusive. I would say we are a RISC architecture (Load/store based/everything happens on registers, fixed instruction word size, shallow pipeline) that happens to have a much simpler instruction decoder & higher instruction level parallelism since our compiler guarantees that the instruction bundle (the 64 bit Very Long Instruction Word containing 4 "syllables" of instructions itself) will only give instructions that will not conflict with anything it is given with or in the pipeline. Other than we are faster (20% higher clock plus 2x higher IPC) and more efficient (Epiphany is single precision only, where we are twice as efficient as them, we also support FP64), there are three quick points: 1. We actually have double the local scratchpad of Epiphany per core, and our SPM banking and register port scheme actually enables us to operate all four functional units within a core simultaneously, while also having data go in and out of the core on the Network on Chip. With Epiphany, you are very limited in what instructions can run together primarily due to port conflicts... the biggest difficulty is that you can't do any sort of control instructions with anything else. 2. As far as the Network on Chip goes, we are able to guarantee all latencies through a strict deterministic static priority routing scheme. Epiphany had 3 levels of it's Network on Chip, one for stores, one for read requests (8x slower than stores), and one for off chip communications. We have a (patent pending) way of simplifying all of this greatly while reducing latency and having greater bit efficiency. 3. Off chip memory bandwidth is extremely important to us. Even on our test chip, we have 4x higher bandwidth than the Epiphany IV, plus lower latency... our chip to chip and memory interface also uses the exact same protocol as our NoC, simplifying things even further. There are a handful of smaller things, though my biggest gripe with Epiphany has always been the lack of bandwidth both on and especially off chip. If you are targeting DSP and similar applications like both Epiphany and we are, you really really need to have the ability to saturate your networks and match compute capabilities with it.

nemo1618 10y ago

This is so cool to hear. I've long been holding out hope that we won't be trapped in the current CPU paradigm forever. Thank you for the work you're doing.