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

41–50 of 97 posts

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

#41

Post by monocasa »

iammyIP wrote: post #10
56245623456 wrote: post #4

Earlier quoted context omitted.

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.

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.

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

#42

Post by mwcampbell »

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…

Would built-in I2S be required for an audio DAC add-on like the Teensy audio adapter [1] to be practical?

[1]: http://pjrc.com/store/teensy3_audio.html

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

#43

Post by mattthebaker »

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…

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 100s of clock cycles for a SPI read.

I really hope they just forgot to mention 100kB+ of RAM on that landing page, and the 16kB data is just a DCACHE.

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

#44

Post by [deleted] »

mattthebaker wrote: post #43
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…

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…

[deleted]

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

#45

Post by TD-Linux »

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

Earlier quoted context omitted.

That speed is quite enough to do audio processing - you can run Opus easily on those microcontrollers. Many other audio processing tasks are simpler. AC97 chips are basically DACs/ADCs, and do no audio processing themselves, so are a bad comparison. However, while most Cortex-M chips have an I2S peripheral to integrate with an external DAC, the HiFive1 doesn't, which might cause some difficulties. Audio out can be im…

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 you linked talks about high end DACs but says nothing about the DSP on the card, other than that it has one, for doing... something (?)

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

#46

Post by Sanddancer »

cmrdporcupine wrote: post #32
mwachs5 wrote: post #26

Earlier quoted context omitted.

You're correct, you can access the 128MBit SPI Flash as any other read-only memory mapped memory -- you can execute out of it or load data (you can also write to it but need to use a seperate channel, it's not directly memory mapped to write). You're also correct on the sizes of the ICache and Scratchpad. You can execute code which resides in the scratchpad, but can't store data in the I-Cache.

Does the MCU expose address lines to wire in external RAM?

No. The only external addressing is through QSPI0, and that only has one chip select line hooked to it. They do make small amounts -- 512k -- of SPI RAM, but that on its own would make the chip boot process interesting.

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

#47

Post by TD-Linux »

mattthebaker wrote: post #43
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…

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 thing I would add in the next revision (that would be more peripherals).

Also note that Quad SPI flash is 4 bits wide, and is NOR flash.

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

#48

Post by TD-Linux »

mwcampbell wrote: post #42
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…

Would built-in I2S be required for an audio DAC add-on like the Teensy audio adapter [1] to be practical? [1]: http://pjrc.com/store/teensy3_audio.html

Yeah, bit banging I2S would be gross. You could, however, use the PWM outputs for audio as long as the requirements aren't too strict. And of course, you could always implement it with extra hardware. Hoping for I2S on the next version :)

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

#50

Post by TD-Linux »

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…

Too late to edit, but I meant to link to this page, which is more specific about this chip's implementation: https://dev.sifive.com/documentation/freedom-e310g-0000-manu...
Post reply on HN