Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sifive.com

Post reply on HN
Print view View original

51–60 of 97 posts

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

#51

Post by mattthebaker »

TD-Linux wrote: post #47
mattthebaker wrote: post #43

Earlier quoted context omitted.

Regarding point 1, this is a terrible design decision. Any low power or high performance uC that requires code in external SPI loads it into and executes from RAM. At 32Mhz it starts to make sense to have an ICACHE, with EMBEDDED Flash on a parallel bus. At 320Mhz you want to cache your RAM. With 320Mhz and external SPI (not even fast parallel NOR), you have to be insane. A single instruction cache miss will cost you…

The limitation that I referred to (same as open-v) is that it's very difficult to get IP for embedded NVRAM, and requires more complicated processes. So this seems like the next best option. Yes, misses are going to be very expensive, but I'd rather have icache than manually paging code (plus you can use the 16KiB internal RAM for tight timing loops). More RAM would of course be better, but probably not the first thi…

Yes, the process trade offs are not so good if you want embedded flash. You need a process that can withstand the high voltages for flash erase, which means thick oxides and slow transistors.

At 320Mhz, you should have icache and paged code. A process that can clock this high should have no problem with RAM densities to offer more than 16kB. Better to mirror what the entire industry does: low clock speed and embedded flash, or better process with faster clocks, more RAM and external flash.

Quad SPI NOR is still SPI, which requires serial timings. You need to serialize address and data with each transaction. Parallel NOR has parallel address and data, and an order of magnitude improved throughput and latency.

There is really no point to 320Mhz with such slow code memory.

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

#52

Post by TD-Linux »

mattthebaker wrote: post #51
TD-Linux wrote: post #47

Earlier quoted context omitted.

The limitation that I referred to (same as open-v) is that it's very difficult to get IP for embedded NVRAM, and requires more complicated processes. So this seems like the next best option. Yes, misses are going to be very expensive, but I'd rather have icache than manually paging code (plus you can use the 16KiB internal RAM for tight timing loops). More RAM would of course be better, but probably not the first thi…

Yes, the process trade offs are not so good if you want embedded flash. You need a process that can withstand the high voltages for flash erase, which means thick oxides and slow transistors. At 320Mhz, you should have icache and paged code. A process that can clock this high should have no problem with RAM densities to offer more than 16kB. Better to mirror what the entire industry does: low clock speed and embedded…

Yeah, even with the Opus application I mentioned, 320Mhz is way overkill - 50Mhz would have been plenty. It kind of seems like for some reason they were able to get a modern process, but only a really tiny die. It's pretty interesting that Open-V made the same tradeoff - 160MHz, but only 8KiB of RAM shared between code and data (with no memory mapped SPI flash).

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

#53

Post by userbinator »

monocasa wrote: post #41
iammyIP wrote: post #10

Earlier quoted context omitted.

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/specifications/

It's a simple ISA, but built to be fast. It's specifically designed to map well to OoO cores at the slight expense of some features on in order cores that give you little boosts (like branch delay slots and other exposed pipeline features). Last I saw, BOOM compared very well to other OoO cores at the same gate count.

If anything I think RISC-V is repeating the same mistakes as MIPS and the original RISCs, by being far too simple and requiring much greater fetch bandwidth in the process.

The performance of MIPS, which it is closest to, has never really been considered anything more than "acceptable". It loses to ARM (which isn't so RISC-y anyway) and x86, so I expect RISC-V to be about the same:

https://www.extremetech.com/extreme/188396-the-final-isa-sho...

http://www.extremetech.com/wp-content/uploads/2014/08/Averag...

Compared to an 8-bit AVR in an Arduino it's definitely much faster, but compared to other 32-bit architectures, it is not.

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

#54

Post by i336_ »

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%20... :D

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

#55

Post by monocasa »

userbinator wrote: post #53
monocasa wrote: post #41

Earlier quoted context omitted.

It's a simple ISA, but built to be fast. It's specifically designed to map well to OoO cores at the slight expense of some features on in order cores that give you little boosts (like branch delay slots and other exposed pipeline features). Last I saw, BOOM compared very well to other OoO cores at the same gate count.

If anything I think RISC-V is repeating the same mistakes as MIPS and the original RISCs, by being far too simple and requiring much greater fetch bandwidth in the process. The performance of MIPS, which it is closest to, has never really been considered anything more than "acceptable". It loses to ARM (which isn't so RISC-y anyway) and x86, so I expect RISC-V to be about the same: https://www.extremetech.com/extreme…

They've made their compressed ISA a first class citizen, with code density that's in the Thumb2 range.

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

#56

Post by BuuQu9hu »

rwmj wrote: post #33
TD-Linux wrote: post #29

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…

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

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.

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

#57

Post by BuuQu9hu »

fuzzythinker wrote: post #13
andkon wrote: post #3

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

Agree, for some who has no idea what RISC-V is, which I'm guessing is more than 50% of visitors, the "why" on the page needs to sell me on why RISC-V is better or at least better for certain things.

https://youtu.be/QTYiH1Y5UV0

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

#58

Post by pjmlp »

wolfgke wrote: post #20
mwcampbell wrote: post #5

Earlier quoted context omitted.

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.

> 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 pro…

> 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

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

#59

Post by mSparks »

TD-Linux wrote: post #45
mSparks wrote: post #40

Earlier quoted context omitted.

Depends what you mean by "enough". 24MHz is "enough" for 20 bits@96kHz ADC and some post processing. But 20 bits@96kHz is not decent. For reasonable SNR, you need at least 24 bits, and even then "the experts" offload to an external CPU http://www.tested.com/tech/pcs/454839-tested-why-high-end-pc... For signal (less audio are more "controller") with high precision you need micro controllers with the power of at least…

Firstly, https://xiph.org/~xiphmont/demo/neil-young.html Secondly, even if you did want to process at 96kHz, you'd have plenty of CPU left to do so. It's only 2x as intensive as 48kHz (this is a 32 bit CPU so using 16 bit vs 32 bit math is mostly the same, sans DSP instructions) and that amount of headroom is likely available, for example: https://www.rockbox.org/wiki/CodecPerformanceComparison Thirdly, the article y…

Sigh,

Firstly, getting from uncompressed at the input to compressed is basic processing.

Seriously, you don't. Non risk instructions often take Multiple cycles, so you can only do a tiny number of them between samples, usually just enough to compress it to fit the bus speed without loss. https://en.m.wikipedia.org/wiki/Cycles_per_instruction

Thirdly, clearly you didn't rtfa.

Fourthly, go disagree on the teensy forum. https://forum.pjrc.com/threads/27364-Teensy-3-1-and-ADC-FIR-...

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

#60

Post by fuzzythinker »

BuuQu9hu wrote: post #57
fuzzythinker wrote: post #13

Earlier quoted context omitted.

Agree, for some who has no idea what RISC-V is, which I'm guessing is more than 50% of visitors, the "why" on the page needs to sell me on why RISC-V is better or at least better for certain things.

https://youtu.be/QTYiH1Y5UV0

Thank you, the video is very informative. Link should definitely be on the site.
Post reply on HN