BeagleBoard Announces BeagleV-Fire with RISC-V and FPGA
tomshardware.com
tomshardware.com
That would allow using the open stack (yosys+nextpnr).
But few vendors provide these documents (QuickLogic), and otherwise most of the supported families are so thanks to reverse engineering. Quite sad.
In practice, most hobbyists will simply avoid garbage vendor tools, and development boards (like this one) that need them.
Instead, they'll get e.g. QuickLogic, Lattice iCE40/ECP5 or GOWIN GW1N/GW2N, on some cheap development board[0].
Yes, hobbyists and students are "the bottom", but winning them has historically been how you eventually win the industry as a whole.
The same chip, but in 250k LUT version has been available on the Microsemi Icicle for $499 since late 2020. You can find that on Digikey and Mouser.
$30 is a good price for FPGA dev board, requires a little creativity https://github.com/q3k/chubby75/tree/master
[1] called E51 when this U54-MC core complex first came out in the FU-540 SoC on the HiFive Unleashed in 2018. That was running at 1.0 - 1.5 GHz vs 667 MHz in this FPGA, but otherwise the same thing.
To adopt a cheaper, more modern, and more powerful FPGA ecosystem that's actually supported by the yosys/nextpnr open stack. And, while at it, the control plane CPU would be standard RISC-V instead of legacy ISA (currently ARM).
Something like Lattice ECP5 or GOWIN's GW2N.
On that, Sipeed recently announced a cheap 135K LUT devboard[0] based on GW2N. Apparently, a version with ~500k LUT is in the works.
0. https://www.cnx-software.com/2023/10/01/sipeed-tang-mega-138...
It's really not.
The problem is that you either need to be able to draw schematics or you need to be able to design in Verilog or VHDL. That means 99.99% of all programmers are excluded.
And this is before we start talking about the FPGA development tools which all suuuuuuuck.
If, however, you have something like the PRU on the Beaglebone Black (or the much more limited PIO on the RP2020 for example), your standard systems programmers can develop code for your board. That's a huge win over using an FPGA.
This, in fact, where I was really hoping RISC-V would shine. Have a couple of high power RV64I cores (Cortex-A equivalent) that can run an OS in soft real time and a couple of low power RV32I cores (Cortex-M equivalent) connected directly to the pins and running in hard real time. And, since everything is all RISC-V, the tooling is the same so you don't have to learn some esoteric thing (TI PRU or RP2040 PIO).
Alas. The problem is that the RISC-V people all want to be making the sexy thing instead of the thing that will ship a zillion units.
(I mean, that Microchip SoC is like $40 in quantity! You can get a pretty powerful ARM SoC for $20 and a remarkably big FPGA for another $20 and be WAY ahead.)
You have perhaps missed the BL808 (C906 applications processor RV64GCV 480MHz, plus RV32GCP 320MHz real-time core, plus RV32EMC 160MHz core primarily controlling the WIFI/BT) and CV1800B (C906 RV64GCV 1 GHz for Linux, plus C906 RV64GC 700 MHz for real-time), both with 64 MB on chip PSRAM and available on boards under $10: Sipeed M1s Dock, Pine64 Ox64, Milk-V Duo.
However, while many things are fine with sequential processing on a few hundred MIPS conventional CPU or PIO, some things need the parallelism of an FPGA fabric. Yes, it's harder to use but that's equally true on your cheap iCE40 (or whatever) attached to an MCU by a few pins.
Beagleboard products are always expensive. They are aimed at purchase-order corporate users, always available in stock in major distributors such as Digikey on the day of announcement, and have got margin built in for the distributor.
Yeah, I'm not surprised I haven't heard of them.
For which chip family?
e.g. BLxxx ones are infamous for lack of docs and I avoid them for that reason, but I haven't had trouble with CH32V family or ESP32-C family.
>getting 404s after I finally dove into the "Community" section of their website which seems to be where they stash the documentation),
Oh, do you perhaps mean the CV1800B used in Milk-V Duo?
They changed the path in the repository, I found it[0] by visiting the parent in the URL's path. Whoever maintains the wiki should either not have linked the blob but the repository, or should have used an actual commit instead of master for the blob.
It's preliminary, but has some 700 pages already (!).
As for the CV1800B, I note that it has an 8051 in the RTC domain. Which misses the whole bloody point of RISC-V.
> It's preliminary, but has some 700 pages already (!).
Then they've only got another 4300 pages to go ... :)
(By comparison: see the AM3359 Technical Reference Manual from TI which is 5100 pages long).
It looks that much larger and much more complex design. It's also been around for a while, having released in 2011.
Unsurprisingly, a significant amount of pages are used to describe the CPU, interrupt controller, memory management and other such ARM-specific cruft.
In contrast, RISC-V is much simpler, cleaner, and much more thoroughly standardized, thus the vendor can simply point to the relevant RISC-V specs.
>Then they've only got another 4300 pages to go ... :)
At least you are just joking :)
The less the documentation needed to describe the same functionality the better. Simplicity is valuable on its own, thus complexity needs be justified.
I doubt it.
Even simple questions like "How many clock cycles to access SPI register X?" wind up surprisingly complicated. And the manufacturer needs to document all of it because there just aren't enough users to figure it all out by experiment. Even if your CPU is 100% bog standard (and these are not), documenting the peripherals takes a ton of work.
Datasheets, in general, tend to be horrible. However, I find that the Chinese datasheets are particularly dreadful whether the chips are simple or complex.
I mean, one of the reasons they gave for it being useful was so they could learn to program FPGAs, so this seems like a moot point. But yeah, the tools suck. Especially Microchip's.