11 ms·

HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

194 points by mwcampbell 10y ago

Klasiaster 10y ago
So does it have a MMU? That would make it even more superior to Arduino boards.
- mwcampbell 10y ago
  It seems to me that an MMU is no good if the board doesn't have enough RAM to run a general-purpose operating system, as opposed to a bare-metal program or a real-time OS like a microcontroller usually uses.
  - wolfgke 10y ago
    > It seems to me that an MMU is no good if the board doesn't have enough RAM to run a general-purpose operating system, as opposed to a bare-metal program or a real-time OS like a microcontroller usually uses. For a realtime operating system at least a Memory Protection Unit (to use the word that ARM introduced for this limited form of an MMU) is very useful since it can easily make the OS much more reliable if a process cannot write to memory adresses of the kernel or other processes. EDIT: Or is such an MPU implied by the support for "Privileged ISA Specification v1.9.1"?
    - pjmlp 10y ago
      > is very useful since it can easily make the OS much more reliable if a process cannot write to memory adresses of the kernel or other processes. If you make use of memory safe systems programming languages on bare metal, like Ada, SPARK, Rust, Oberon-07 than it isn't usually an issue, since the unsafe code will be quite constrained. For example, http://www.astrobe.com/boards.htm http://www.astrobe.com/boards.htm
- 56245623456 10y ago
  The website says it is conforming to "RISC-V Privileged ISA Specification, Version 1.9.1" which seems to specify a paging mechanism. I didn't read all of it though, so I may have overlooked an "optional" or something.
  - rwmj 10y ago
    The most basic option for RISC-V is base + bound in M-mode which isn't paging and can barely be described as an "MMU". (Of course RISC-V also supports much more advanced options)
- mwachs5 10y ago
  The RISC-V ISA defines different privilege levels: Machine, Hypervisor, Supervisor, User. It is possible for a chip to conform to the RISC-V Privilege Spec v1.9 by only implementing the bare metal or Machine mode, which is what the chip on this board does. So the chip on this board does not have User mode or an MMU.
andkon 10y ago
For someone who has no idea what RISC-V is but loves making things with Arduino, what new things could I do with this?
- 56245623456 10y ago
  I think the RISC-V is way faster, otherwise you probably won't have any advantage, except knowing that the whole ISA is opensource in contrast to AVR chips.
  - dmitrygr 10y ago
    It promises to maybe be faster. Has no internal flash, cannot be bought in volume if you intend to actually make anything, has a very immature toolchain, and currently is a theory only.
    - ajross 10y ago
      These SiFive folks claim to have working silicon, there are what look like some power measurements on their site, and there are photographs of boards available for a claimed ship date in ~3 weeks. It's not in my hands personally, but they seem to be over the vapor hump. I found it an exciting enough product to drop $60 on, anyway.
    - mastax 10y ago
      Your disclaimers are fair in that if you want an Arduino, buy an Arduino. But if a 320 MHz anything is slower than a 24 MHz AVR then the sky is falling.
  - iammyIP 10y ago
    The RISC-V seems to have it's focus on being open and being simple, not so much on being the fastest. The specs are only 130 pages. https://riscv.org/risc-v-foundation/ https://riscv.org/risc-v-foundation/ https://riscv.org/specifications/ https://riscv.org/specifications/
    - 10y ago
cmrdporcupine 10y ago
320mhz clock speed but only 16KB of RAM. RISC-V is appealing but if I'm stuck at 32KB or less of RAM I'd stick with the Parallax Propeller which has 8 parallel 100mhz cores.
- wolfgke 10y ago
  > Parallax Propeller which has 8 parallel 100mhz cores. According to https://en.wikipedia.org/w/index.php?title=Parallax_Propeller&oldid=740196753#Speed_and_power_management https://en.wikipedia.org/w/index.php?title=Parallax_Propelle... it is only up to 80 MHz.
  - cmrdporcupine 10y ago
    Overclocks safely to 100mhz
- cr0sh 10y ago
  I'm not sure that's the whole story - specs read: Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad I'm wondering if it's possible to combine that or dice it in some way? On top of that, the program resides in SPI flash (128 Mbit -> 16 meg). EDIT: ok - the above makes no sense, so yes, on 16K on-board RAM (and the other is for cache). Short of more info, I'd be willing to bet that some of that flash can be set aside (or used like) variable space (albeit at a slower speed), and the on-board memory is more for high-speed stuff (and you'd have to swap things in/out - though likely they'll have a library for all of that - maybe). If all of that is true (or close to the truth) - well, I don't know if it would be better than the propeller or whatnot, but it certainly looks interesting... EDIT: Reading the infosheet on the processor: https://dev.sifive.com/documentation/freedom-e310g-0000-manual/ https://dev.sifive.com/documentation/freedom-e310g-0000-manu... It does seem like the flash can be used for data and program space - and it appears like it can be read/written to from the cpu - so it's kinda like the flash storage on the Arduino. I would imagine it can be used similar - although slower - as variable memory (given a proper lib); and "paged" into the faster on-board 16k RAM.
  - mwachs5 10y ago
TD-Linux 10y ago
I looked over the Chisel source code and the barebones datasheet [1]. This chip has a couple of unique features: 1. It doesn't have any onboard NVRAM (same limitation as the open-v). However, it does have a directly memory mapped quad-SPI peripheral and icache, which is a great alternative and might be better for applications that require a large amount of data. Note that an icache would still be required even if it had onboard NVRAM, because of its speed. You could also make swappable game cartridges, for example. 2. It has enough RAM and speed to run Opus. 3. The rest of the peripheral set is pretty barebones, no analog like the open-v has. No I2C or I2S without bitbanging, either. 4. The boot ROM has peripheral information stored in it. You might be able to have one binary that boots on different types of cores using this. [1] https://dev.sifive.com/documentation/freedom-e300-platform-brief/ https://dev.sifive.com/documentation/freedom-e300-platform-b...
- rwmj 10y ago
  I'm worried this leads to the zoo of random hardware that we see on ARM, which makes supporting Linux distros on ARM such a PITA. It would be better if the basic hardware — serial ports and such — was in a standard location for all RISC-V machines, and all the rest of the hardware was discoverable at runtime (like PCs, mostly).
  - aray 10y ago
    It looks like we're moving towards a solution (in a slow, jerky, shambling way) with replacing hardcoded boardfiles with device trees. If RISC-V does this well out of the gate (like with IBM's old school Open Firmware) and has great shiny device tree support, I think we might end up like x86 -- where a single thumbdrive can boot almost any x86 machine under the sun.
  - BuuQu9hu 10y ago
    HiFive1 isn't something you would run a Linux distro on anyway, especially since the ISA is still evolving and it will be using an early version.
  - kristoffer 10y ago
    Or you can solve it as done in GRLIB (www.gaisler.com/index.php/downloads/leongrlib), with having all on-chip peripheral information (memory & irq map, etc) specified in a ROM configuration area (which is automatically generated at synthesis time).
smilekzs 10y ago
320 MHz core clock is very impressive, compare to <= 200 MHz typical of Cortex-M3/4 impls. However at this freq, flash (instruction) readout becomes the bottleneck. While Cortex-M chips typically include some on-chip flash acceleration, this chip instead went for external flash + I-Cache. The new Cortex-M7 chip STM32F7 has both flash accel and I-Cache. It remains to be seen whether this chip can sustain real-world workloads at 320 MHz with 0 wait state. Even at 200 MHz it has the potential to replace proprietary fixed-point low-end DSP chips.
- childintime 10y ago
  Modern non-volatile RAM technologies (like XPoint) would be perfect for chips like this. Much faster than flash and usable as RAM.
ChuckMcM 10y ago
I like that 3.3V and 5V I/O is supported, so many Arduino shields assume 5V and so "compatible" boards like the ST Nucleo boards aren't actually compatible.
deleted 10y ago
[deleted]
i336_ 10y ago
Two points: a short question and a longer theory about why only 16KB. The question: how viable is an open-source, publicly-auditable secure boot implementation? Not TPM theater or whatever, but a hardened hardware configuration that could be used to implement truly verifiable boot. (If anyone from RISC-V is reading this, I think there is a very noteworthy amount of money in building a truly securely bootable reference design. Hopefully lots of people have already told you that.) -- Next, regarding why only 16KB RAM... I'm very interested in the potential of open source ISA, but admittedly completely ignorant about chip design. With this in mind, I have a theory that the manufacturers deliberately provided a ridiculously low amount of RAM in order to make it impossible[1] to run Linux on it and so keep it out of the mass market. Considering the CPU is full 320MHz I don't think this is because they have some other product up their sleeve. Rather, looking at the fact that this is the first marketed product they have available that's an actual real chip (!!), I would expect that either the chip itself and/or the chipset likely has bugs in it. They've gone through many internal revisions, and now they feel comfortable with putting the chipset out there for public testing to get bugreports from the field. My thinking is that applications that will play nice with 16KB of RAM will stress the CPU out significantly less than full Linux would, similarly to how doing basic tasks on a faulty x86 PC may work for years but compiling GCC will find broken bits in RAM sooner or later. There's also the fact that such projects are also generally quieter as a whole than the thundering herd of people wanting to run Linux on things. Don't forget, RISC-V has been nothing more than a bunch of VHDL for years, running on "perfect" FPGAs that don't require you to think about low-level electrical niggles and whatnot. If I'm understanding correctly, this is the first time a real RISC-V chip run has been done (?) and made available to the market. Considering the success of ARM (or, more generically, the market sector of "little PCBs that run Linux"), RISC-V needs to stay competitive and attractive - and full Linux that constantly oopses in mm.c will make RISC-V look real bad real fast. I definitely want the ISA to thrive, and if my assumptions are correct capping the RAM makes an inelegant-yet-elegant sort of sense. I expect RISC-V will be running Linux on real fabbed chips within the next two years. [1]: Well, practically impossible. If you don't mind 300KB/s RAM (yes, KB/s, not MB/s) there's always http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20... :D
- 10y ago
guomanmin 10y ago
Participate in Atlassian Research My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.   We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.    If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon! Cheers,   Angela Guo aguo@atlassian.com

194 points by mwcampbell 10y ago

Klasiaster 10y ago

So does it have a MMU? That would make it even more superior to Arduino boards.

mwcampbell 10y ago
It seems to me that an MMU is no good if the board doesn't have enough RAM to run a general-purpose operating system, as opposed to a bare-metal program or a real-time OS like a microcontroller usually uses.
- wolfgke 10y ago
  > It seems to me that an MMU is no good if the board doesn't have enough RAM to run a general-purpose operating system, as opposed to a bare-metal program or a real-time OS like a microcontroller usually uses. For a realtime operating system at least a Memory Protection Unit (to use the word that ARM introduced for this limited form of an MMU) is very useful since it can easily make the OS much more reliable if a process cannot write to memory adresses of the kernel or other processes. EDIT: Or is such an MPU implied by the support for "Privileged ISA Specification v1.9.1"?
  - pjmlp 10y ago
    > is very useful since it can easily make the OS much more reliable if a process cannot write to memory adresses of the kernel or other processes. If you make use of memory safe systems programming languages on bare metal, like Ada, SPARK, Rust, Oberon-07 than it isn't usually an issue, since the unsafe code will be quite constrained. For example, http://www.astrobe.com/boards.htm http://www.astrobe.com/boards.htm
56245623456 10y ago
The website says it is conforming to "RISC-V Privileged ISA Specification, Version 1.9.1" which seems to specify a paging mechanism. I didn't read all of it though, so I may have overlooked an "optional" or something.
- rwmj 10y ago
  The most basic option for RISC-V is base + bound in M-mode which isn't paging and can barely be described as an "MMU". (Of course RISC-V also supports much more advanced options)
mwachs5 10y ago
The RISC-V ISA defines different privilege levels: Machine, Hypervisor, Supervisor, User. It is possible for a chip to conform to the RISC-V Privilege Spec v1.9 by only implementing the bare metal or Machine mode, which is what the chip on this board does. So the chip on this board does not have User mode or an MMU.

andkon 10y ago

For someone who has no idea what RISC-V is but loves making things with Arduino, what new things could I do with this?

56245623456 10y ago
I think the RISC-V is way faster, otherwise you probably won't have any advantage, except knowing that the whole ISA is opensource in contrast to AVR chips.
- dmitrygr 10y ago
  It promises to maybe be faster. Has no internal flash, cannot be bought in volume if you intend to actually make anything, has a very immature toolchain, and currently is a theory only.
  - ajross 10y ago
    These SiFive folks claim to have working silicon, there are what look like some power measurements on their site, and there are photographs of boards available for a claimed ship date in ~3 weeks. It's not in my hands personally, but they seem to be over the vapor hump. I found it an exciting enough product to drop $60 on, anyway.
  - mastax 10y ago
    Your disclaimers are fair in that if you want an Arduino, buy an Arduino. But if a 320 MHz anything is slower than a 24 MHz AVR then the sky is falling.
- iammyIP 10y ago
  The RISC-V seems to have it's focus on being open and being simple, not so much on being the fastest. The specs are only 130 pages. https://riscv.org/risc-v-foundation/ https://riscv.org/risc-v-foundation/ https://riscv.org/specifications/ https://riscv.org/specifications/
  - 10y ago

cmrdporcupine 10y ago

320mhz clock speed but only 16KB of RAM. RISC-V is appealing but if I'm stuck at 32KB or less of RAM I'd stick with the Parallax Propeller which has 8 parallel 100mhz cores.

wolfgke 10y ago
> Parallax Propeller which has 8 parallel 100mhz cores. According to https://en.wikipedia.org/w/index.php?title=Parallax_Propeller&oldid=740196753#Speed_and_power_management https://en.wikipedia.org/w/index.php?title=Parallax_Propelle... it is only up to 80 MHz.
- cmrdporcupine 10y ago
  Overclocks safely to 100mhz
cr0sh 10y ago
I'm not sure that's the whole story - specs read: Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad I'm wondering if it's possible to combine that or dice it in some way? On top of that, the program resides in SPI flash (128 Mbit -> 16 meg). EDIT: ok - the above makes no sense, so yes, on 16K on-board RAM (and the other is for cache). Short of more info, I'd be willing to bet that some of that flash can be set aside (or used like) variable space (albeit at a slower speed), and the on-board memory is more for high-speed stuff (and you'd have to swap things in/out - though likely they'll have a library for all of that - maybe). If all of that is true (or close to the truth) - well, I don't know if it would be better than the propeller or whatnot, but it certainly looks interesting... EDIT: Reading the infosheet on the processor: https://dev.sifive.com/documentation/freedom-e310g-0000-manual/ https://dev.sifive.com/documentation/freedom-e310g-0000-manu... It does seem like the flash can be used for data and program space - and it appears like it can be read/written to from the cpu - so it's kinda like the flash storage on the Arduino. I would imagine it can be used similar - although slower - as variable memory (given a proper lib); and "paged" into the faster on-board 16k RAM.
- mwachs5 10y ago

TD-Linux 10y ago

I looked over the Chisel source code and the barebones datasheet [1]. This chip has a couple of unique features: 1. It doesn't have any onboard NVRAM (same limitation as the open-v). However, it does have a directly memory mapped quad-SPI peripheral and icache, which is a great alternative and might be better for applications that require a large amount of data. Note that an icache would still be required even if it had onboard NVRAM, because of its speed. You could also make swappable game cartridges, for example. 2. It has enough RAM and speed to run Opus. 3. The rest of the peripheral set is pretty barebones, no analog like the open-v has. No I2C or I2S without bitbanging, either. 4. The boot ROM has peripheral information stored in it. You might be able to have one binary that boots on different types of cores using this. [1] https://dev.sifive.com/documentation/freedom-e300-platform-brief/ https://dev.sifive.com/documentation/freedom-e300-platform-b...

rwmj 10y ago
I'm worried this leads to the zoo of random hardware that we see on ARM, which makes supporting Linux distros on ARM such a PITA. It would be better if the basic hardware — serial ports and such — was in a standard location for all RISC-V machines, and all the rest of the hardware was discoverable at runtime (like PCs, mostly).
- aray 10y ago
  It looks like we're moving towards a solution (in a slow, jerky, shambling way) with replacing hardcoded boardfiles with device trees. If RISC-V does this well out of the gate (like with IBM's old school Open Firmware) and has great shiny device tree support, I think we might end up like x86 -- where a single thumbdrive can boot almost any x86 machine under the sun.
- BuuQu9hu 10y ago
  HiFive1 isn't something you would run a Linux distro on anyway, especially since the ISA is still evolving and it will be using an early version.
- kristoffer 10y ago
  Or you can solve it as done in GRLIB (www.gaisler.com/index.php/downloads/leongrlib), with having all on-chip peripheral information (memory & irq map, etc) specified in a ROM configuration area (which is automatically generated at synthesis time).

smilekzs 10y ago

320 MHz core clock is very impressive, compare to <= 200 MHz typical of Cortex-M3/4 impls. However at this freq, flash (instruction) readout becomes the bottleneck. While Cortex-M chips typically include some on-chip flash acceleration, this chip instead went for external flash + I-Cache. The new Cortex-M7 chip STM32F7 has both flash accel and I-Cache. It remains to be seen whether this chip can sustain real-world workloads at 320 MHz with 0 wait state. Even at 200 MHz it has the potential to replace proprietary fixed-point low-end DSP chips.

childintime 10y ago
Modern non-volatile RAM technologies (like XPoint) would be perfect for chips like this. Much faster than flash and usable as RAM.

ChuckMcM 10y ago

I like that 3.3V and 5V I/O is supported, so many Arduino shields assume 5V and so "compatible" boards like the ST Nucleo boards aren't actually compatible.

deleted 10y ago

[deleted]

i336_ 10y ago

Two points: a short question and a longer theory about why only 16KB. The question: how viable is an open-source, publicly-auditable secure boot implementation? Not TPM theater or whatever, but a hardened hardware configuration that could be used to implement truly verifiable boot. (If anyone from RISC-V is reading this, I think there is a very noteworthy amount of money in building a truly securely bootable reference design. Hopefully lots of people have already told you that.) -- Next, regarding why only 16KB RAM... I'm very interested in the potential of open source ISA, but admittedly completely ignorant about chip design. With this in mind, I have a theory that the manufacturers deliberately provided a ridiculously low amount of RAM in order to make it impossible[1] to run Linux on it and so keep it out of the mass market. Considering the CPU is full 320MHz I don't think this is because they have some other product up their sleeve. Rather, looking at the fact that this is the first marketed product they have available that's an actual real chip (!!), I would expect that either the chip itself and/or the chipset likely has bugs in it. They've gone through many internal revisions, and now they feel comfortable with putting the chipset out there for public testing to get bugreports from the field. My thinking is that applications that will play nice with 16KB of RAM will stress the CPU out significantly less than full Linux would, similarly to how doing basic tasks on a faulty x86 PC may work for years but compiling GCC will find broken bits in RAM sooner or later. There's also the fact that such projects are also generally quieter as a whole than the thundering herd of people wanting to run Linux on things. Don't forget, RISC-V has been nothing more than a bunch of VHDL for years, running on "perfect" FPGAs that don't require you to think about low-level electrical niggles and whatnot. If I'm understanding correctly, this is the first time a real RISC-V chip run has been done (?) and made available to the market. Considering the success of ARM (or, more generically, the market sector of "little PCBs that run Linux"), RISC-V needs to stay competitive and attractive - and full Linux that constantly oopses in mm.c will make RISC-V look real bad real fast. I definitely want the ISA to thrive, and if my assumptions are correct capping the RAM makes an inelegant-yet-elegant sort of sense. I expect RISC-V will be running Linux on real fabbed chips within the next two years. [1]: Well, practically impossible. If you don't mind 300KB/s RAM (yes, KB/s, not MB/s) there's always http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20... :D

10y ago

guomanmin 10y ago

Participate in Atlassian Research My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.   We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.    If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon! Cheers,   Angela Guo aguo@atlassian.com