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

61–70 of 97 posts

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

#61

Post by kristoffer »

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

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

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

#62

Post by kobeya »

i336_ wrote: post #54

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

SiFive is working on two chips. This one is basically an atmel competitor. They are also working on a workstation class many core chip.

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

#63

Post by david-given »

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…

This is the first time I've come across this concept (outside the ESP ecosystem); just to check I'm understanding this correctly, this means I can hook up a serial SRAM or equivalent device and the hardware will automatically demand-page arbitrary amounts of code out of it, right?

What's the throughput like? Can this be used for data as well (which will need caching too)?

Because this suddenly makes the device much more interesting; for everything I've done with microcontrollers (which, I'll admit, tends to be abusive), I would happily trade performance for some more RAM.

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

#64

Post by TickleSteve »

david-given wrote: post #63
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…

This is the first time I've come across this concept (outside the ESP ecosystem); just to check I'm understanding this correctly, this means I can hook up a serial SRAM or equivalent device and the hardware will automatically demand-page arbitrary amounts of code out of it, right? What's the throughput like? Can this be used for data as well (which will need caching too)? Because this suddenly makes the device much m…

No, the QSPI device is simply memory mapped as in quite a lot (most) microcontrollers.

The external QSPI FLASH just appears in the normal memory map, no demand-paging.

Normally used for eXecute-In-Place code (XIP) when the code is too large for the internal FLASH.

There is a performance trade-off, and external QSPI FLASH might run its bus at (for example) 50MHz, but thats still much slower than internal FLASH directly attached to the bus.

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

#65

Post by pjc50 »

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…

Most sensible people stick to 16 bits @ 48kHz, especially if it's not a pro-audio device but just something with a MEMS mic and 8ohm speaker.

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

#66

Post by pawadu »

kristoffer wrote: post #61
rwmj wrote: post #33

Earlier quoted context omitted.

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

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

or we could continue using device trees, which are much more expressive and were actually designed for this purpose.

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

#67

Post by trsohmers »

ChuckMcM wrote: post #39
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…

You can bit bang a lot with 320Mhz cycle time :-). That said I wonder if we'll see a common standard emerge for an 'open' serial protocol. Sort of PCIe lite which runs at say 250Mhz over a pair of LVDS pins that you make into an AHB bus master in the memory matrix. That would really open up the peripheral market.

The frequency limit for bit banging is usually limited by the GPIO pins (well, their drivers) rather than the core clock. I use some ~250MHz PIC32MZ's with their GPIOs capping out at around 50MHz, and even the raspberry pi with a core clock of ~1GHz can only bit bang with its GPIOs up to ~60MHz without running into problems. As for LVDS, it takes up more area and power, and you usually need to license the IP block rather than it being available for free from the standard cell library provider.

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

#68

Post by pawadu »

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…

To be fair, the new 64-bit ARMs are becoming "more RISC-y" and have the same problems as MIPS.

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

#69

Post by [deleted] »

ChuckMcM wrote: post #39
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…

You can bit bang a lot with 320Mhz cycle time :-). That said I wonder if we'll see a common standard emerge for an 'open' serial protocol. Sort of PCIe lite which runs at say 250Mhz over a pair of LVDS pins that you make into an AHB bus master in the memory matrix. That would really open up the peripheral market.

[deleted]

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

#70

Post by pjc50 »

i336_ wrote: post #54

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

The whole of your second point is ridiculous conspiracy theory. It is perfectly reasonable to do enough formal verification to ensure that your chip works first time. Linux is not going to "stress" your chip more. And nobody deliberately cuts out a viable market sector unless they've got another product to put in it.

On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM. People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package.

Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves. I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days.

Post reply on HN