5 ms·

They're also doing silicon: https://www.crowdsupply.com/sifive/hifive1 https://www.crowdsupply.com/sifive/hifive1 Along with: https://www.crowdsupply.com/onchi

by vhodges 10y ago

They're also doing silicon: https://www.crowdsupply.com/sifive/hifive1 https://www.crowdsupply.com/sifive/hifive1 Along with: https://www.crowdsupply.com/onchip/open-v https://www.crowdsupply.com/onchip/open-v The fifth RISC-V workshop is on right now and being live blogged at: http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-one/ http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-da...

ant6n 10y ago
Neat. Does that board run linux? Can I hook up a screen, mouse and keyboard?
- vhodges 10y ago
  No, it's more of an arduino clone.
- duskwuff 10y ago
  No. The SiFive part is a microcontroller -- it has 16 KB of RAM.
  - ant6n 10y ago
    Huh, I thought that was the cache. 320Mhz, but 16KB Ram. That seems like an odd combination. Quake ran on a 75MHz cpu, but needed 8MB or ram.
    - wyldfire 10y ago
      Quake was targeted on a CISC-design general purpose CPU, on a very different process from modern ones. Those factors likely explain much of the difference in clock speed. They just couldn't make 320MHz parts as easily then. Even modern x86 CPUs are RISC inside and have microcode to execute the CISC instructions. These particular RISC-V parts are targeting the microcontroller marketplace where there's little RAM required.
      - wang_li 10y ago
        It's a bit silly to be talking RISC and CISC these days. The big idea behind RISC is to spend your transistor budget on minimizing the cycle time of a smaller core set of instructions. However, transistor count has been doubling for quite some time, and clock frequency has gone up by a factor of 100. The idea behind RISC no longer applies. This is observed in the numbers and the fact that every processor manufacturer has been adding video engines, crypto engines and vector units to their processors.
    - marssaxman 10y ago
      It's a common configuration for a microcontroller. You're not going to be rendering graphics on a machine like this; you're going to be spending most of the time asleep, to save power and extend battery life, with occasional quick bursts of interrupt-triggered activity which mostly consist of interacting with peripherals. You generally run the processor at a high clock rate because you're trying to get back to sleep as soon as possible, not because you're actually doing anything computationally intensive. Software for a device like this typically relies heavily on statically-allocated data structures, with limited use of the stack and no dynamic memory allocation at all. It's therefore generally easy to figure out how much RAM you actually need and fit your data structures efficiently into whatever's available. You're not going to be running threads with independent stacks or trying to keep a lot of heap space open to avoid fragmentation; you're just going to use static vars and fixed-length arrays, and the compiler will pack it all in for you.
- deleted 10y ago
  [deleted]

by vhodges 10y ago

ant6n 10y ago

Neat. Does that board run linux? Can I hook up a screen, mouse and keyboard?

vhodges 10y ago
No, it's more of an arduino clone.
duskwuff 10y ago
No. The SiFive part is a microcontroller -- it has 16 KB of RAM.
- ant6n 10y ago
  Huh, I thought that was the cache. 320Mhz, but 16KB Ram. That seems like an odd combination. Quake ran on a 75MHz cpu, but needed 8MB or ram.
  - wyldfire 10y ago
    Quake was targeted on a CISC-design general purpose CPU, on a very different process from modern ones. Those factors likely explain much of the difference in clock speed. They just couldn't make 320MHz parts as easily then. Even modern x86 CPUs are RISC inside and have microcode to execute the CISC instructions. These particular RISC-V parts are targeting the microcontroller marketplace where there's little RAM required.
    - wang_li 10y ago
      It's a bit silly to be talking RISC and CISC these days. The big idea behind RISC is to spend your transistor budget on minimizing the cycle time of a smaller core set of instructions. However, transistor count has been doubling for quite some time, and clock frequency has gone up by a factor of 100. The idea behind RISC no longer applies. This is observed in the numbers and the fact that every processor manufacturer has been adding video engines, crypto engines and vector units to their processors.
  - marssaxman 10y ago
    It's a common configuration for a microcontroller. You're not going to be rendering graphics on a machine like this; you're going to be spending most of the time asleep, to save power and extend battery life, with occasional quick bursts of interrupt-triggered activity which mostly consist of interacting with peripherals. You generally run the processor at a high clock rate because you're trying to get back to sleep as soon as possible, not because you're actually doing anything computationally intensive. Software for a device like this typically relies heavily on statically-allocated data structures, with limited use of the stack and no dynamic memory allocation at all. It's therefore generally easy to figure out how much RAM you actually need and fit your data structures efficiently into whatever's available. You're not going to be running threads with independent stacks or trying to keep a lot of heap space open to avoid fragmentation; you're just going to use static vars and fixed-length arrays, and the compiler will pack it all in for you.
deleted 10y ago
[deleted]