10 ms·
I have been a big fan of the RISC-V efforts. Arm's attack is actually heartening in the sense that it confirms the perceived threat from RISC-V is real. This
by sverige 8y ago
I have been a big fan of the RISC-V efforts. Arm's attack is actually heartening in the sense that it confirms the perceived threat from RISC-V is real. This is a moment on the path that makes me realize real progress is being made for RISC-V.
The development of new technology seems to go so slow while it's happening; it's only in hindsight that it seems it's always and inevitably been this way. Still a long way from running OpenBSD on a 17" laptop with nothing but open source hardware inside, but it's a nice moment.
- waterhouse 8y agoIllustrating with the cliche... they ignore you they laugh at you they fight you <======= you win Now, for something substantial to say... I was looking into computers that can run heavily parallelized grep, and I looked at Adapteva's 16-core Parallella and their 1024-core Epiphany thing, which I think are based on RISC-V (possibly an extension thereto) (EDIT: I'm wrong, see below). It seems that the sole engineer of Adapteva had "left Adapteva in January [2017] to take a position as a program manager at DARPA", and that's the last blog post from the company's website. So... Is anyone working on anything like that, that is currently available or close to available?
- _chris_ 8y agoAdapteva did not use RISC-V. Andreas Olofsson said that, if there was another version, he would probably use RISC-V. [http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/ http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...]
- vidarh 8y agoI don't know of anyone doing something similar. GreenArrays is the closest I'm aware of in terms of number of cores, but their cores are far more minimalistic. XMOS Xcore is another one that is similar-ish. One of the problems Adapteva kept facing, and that I think XMOS did too (and that's caused their change in focus to specifically market voice processing solutions rather than focus on their chips), is that they're suited for a very specific nice: Larger CPUs are way better for things that need high single-core performance and are hard to decompose. GPUs are way better for anything that's mostly single-instruction multiple-data. That is, anywhere where you have a small number of instruction streams doing the same two large arrays. Things like Epiphany and XMOS Xcore do have some appeal in really low power applications, but they'll do best in cases where you have multiple fundamentally divergent instruction streams (lots of branching). Even then, you need enough cores that you can't just pick a bigger CPU and timeslice. Conceptually it really appeals to me, but ever since the days of the Transputer, we've struggled to decompose problems well enough to make many-core designs like Epiphany compete well with ever-faster single-core performance and now coupled with GPU's to slice away the SIMD type problems. I'm still a fan, and have two Parallelas, and find it really sad that he wasn't able to get more traction, as I think you need to get it to an inflection point with more RAM per core and more cores per chip (the Epiphany V might have done that if it had become commercially available, or e.g. on a PCIe card) to allow people to more realistically find the right problems to solve on them. Part of the challenge is that unlike for GPUs, there are no problems that are really screaming out for this architecture, especially not as single core performance for CPUs have skyrocketed, and you can compensate for the lower number via multithreading. For Epiphany type architectures to make sense you need problems where slow-ish single thread performance can be compensates by an ability to run far more in parallel and/or where deterministic latency for communication that is easy to reason about can compensate (e.g. for Epiphany you can relatively easily count "hops" to know how many cycles accessing the memory of any given other core will take, so if you're careful you can use that to do lock-free memory accesses across cores).
- lnsru 8y agoSadly it is still very long way to open source laptop. Remember, processor or SoC contains not only RISC-V core, but also many peripherals. Some peripherals are easy to design (like UARTs and I2Cs), but gpu, pcie, ddr memory and networking aren’t. The question is who will deliver these as open source implementations. IMHO these are not attractive problems to solve in academia, because they are already available as commercial closed source products and lacks novelty.
- phire 8y agoI think a bigger issue is patents. Designing a decent CPUs without violating any patents is easy. Almost all CPUs today follow design patterns which were established back in the mid 80s and early 90s. All those original patents have now expired and you can sidestep around the newer ones. Things like GPUs have evolved massively since the late 90s, gaining support for pixel shaders, vertex shaders, moving to unified core designs, gpu compute and establishing new threading models. And all these things have bled back into the Graphics standards. It would be really hard to design a gpu implementing even a 10 year old standard like OpenGL ES 2.0 without violating any patents. And it will be even worse with things like pci-e, ddr and networking controllers. You can't design around the patents without breaking compatibility because there are standards enforcing you to follow the patents.
- dvfjsdhgfv 8y ago> You can't design around the patents without breaking compatibility because there are standards enforcing you to follow the patents. We could finally learn from this lesson and not support in any way any standards whose implementations require patent licensing.
- madez 8y agoWe do not have to follow the standards that prevent open source solutions. If the price for having an open source computer is old technology or "nonstandard" solutions, then I'm more than happy to pay it.
- 8y ago
- writepub 8y agoI think you're more enamored by the idea of open source hardware than to actually benefit from it directly. And working in semiconductors long enough, I can guarantee that an open ISA without licensing restrictions does not for a fully open source chip, or even core make
- close04 8y agoWanted to say just about the same thing. RISC-V presents a lot of possibilities. Whether they turn into reality is a whole different matter. Same goes for the following statement: "Proprietary products can be severely insecure, and because they can’t benefit from years of scrutiny from open source developers and industry experts" Just because you can benefit from something doesn't mean you will. Heartbleed taught me this lesson again to make sure. So while I'm excited about the new possibilities, I'm managing my expectations at the moment.
- craftyguy 8y agoPretty sure not even RISC-V is "open source hardware", in a meaningful way, unfortunately. There's a lot more to building a platform than the instruction set of the CPU. I've yet to see anyone building an open source hardware platform using RISC-V.. I would be thrilled to be proven wrong, so please do if you can!
- snvzz 8y agolowrisc and pulpino are just that (SoC and microcontroller respectively) There's also a few open CPU core efforts, but most relevant are perhaps Rocket, the reference implementation (single-issue in-order) and boom (out-of-order), a performance oriented implementation.
- sasaf5 8y agoSure, we just need someone to design and mass-manufacture an open source multi-gigabyte RAM chip, then the same for a non-volatile memory.