Microsemi announced a “HiFive Unleashed Expansion Board” built on its PolarFire FPGA that adds PCIe and USB expansion for the RISC-V-based, Linux driven HiFive Unleashed SBC.


cc: @vertigo @jjg @LinuxSocist
#microsemi #pcie #fpga #hifive #riscv #sbc #linux

@h @LinuxSocist @vertigo is love to have one of those #hifive to play with :)

Aside from that, I need to figure out how much FPGA I need to synthesize a Linux-capable RISC-V core.

I want to start making a RISC-V compute module for #rain one way or another 😁

@jjg @LinuxSocist@icosahedron.website @h Artix 7 series, or Zynq 7 series chips are known to work, iirc.

@vertigo @h @LinuxSocist very cool! Where’s the best place to get started? I’m super green on fpga stuff

@jjg @LinuxSocist@icosahedron.website @h For fpga kits, probably Digilent would be my first choice.

@vertigo @h @LinuxSocist so are there “images” (are the called “IP cores” maybe) of chips I can use directly or is it a matter of designing the cpu from scratch (or something in-between)?

I’ve read a little about building application-specific logic with fpga but not whole cpus much.

@jjg @LinuxSocist@icosahedron.website @h Most cores are given in source form. Verilog or VHDL are the most popular. Some RISC-V cores are given in a new language called Chisel.

@jjg @LinuxSocist@icosahedron.website @h To make use of these, you'll need a compiler for these languages so you can "connect" the core to other peripherals on the chip, and to generate a bitstream for your specific chip and surrounding circuit.

@jjg @LinuxSocist @h @vertigo I've seen a 68000 using an FPGA. A bit of googling revealed this one: sites.google.com/site/olivier2

There also seems to be a bunch of soft cores implementing 8-bit CPU's as well if you want something simpler.

@vertigo @h @LinuxSocist my long-term goal is to design a module that is more-or-less pin (doesn’t need to be as compact, just electrically similar ) compatible with the SOPINE modules I’m using now, but with a RISC-V cpu instead of ARM.

@jjg @LinuxSocist@icosahedron.website @h You'll definitely need to use a compiler for this. I am certain Digilent's kits won't be pin compatible with much of anything.

If Sifive has bitstreams for download, it'll be for a self-standing computer running Linux.

@vertigo @h @LinuxSocist Awesome, thank-you for all the info

So if I want to design a custom board around SiFive's chip, but I can't get the chip, could I use a "raw" FPGA loaded with their bitstream instead?

I imagine I'd start with a dev board to learn the ropes, but I'll have to design a custom board eventually anyway so the dev board doesn't have to do everything or work long-term.

@LinuxSocist @h @vertigo

(fwiw, I'm not married to SiFive, but it's the only Linux-compatible RISC-V implementation I'm aware of. Happy to consider others :) )

@jjg @h @LinuxSocist@icosahedron.website Right now, it is the only one in volume silicon.

@jjg Asking just out of sheer ignorance... Is there any potential for cross-polination and reuse between Raiden and the Kestrel projects? @LinuxSocist @vertigo

@h @LinuxSocist@icosahedron.website @jjg At this point in time, unlikely. Raiden is focused on HPC, while I'm focusing more on personal computing and freedom. As I scale up, I suppose some future Kestrel can meet Raiden requirements, or Raiden can be scaled down, and we can meet in the middle. But, for now, he's advancing on his project so much faster than I am on mine that I don't see much overlap at all.

@vertigo @LinuxSocist @h

That's only because I'm using off-the-shelf -parts ;)

What I'm on the hunt for next is a RISC-V compute module that I can use in a parallel machine; maybe there is some overlap between this and a part of Kestrel that could be shared?

@jjg @h @LinuxSocist@icosahedron.website Kestrel is not far enough along to offer any help here. I'm only just now learning how to use the most basic form of the Tile Link interconnect (TL-UL), and I do not yet support any atomic instructions yet (requires TL-HL at a minimum; full TL is preferred). Sifive's pays will have better support for HPC.

@vertigo @jjg @LinuxSocist I'm asking because some new directions I'm taking with the work I'm doing increasingly suggest that some sort assistance from machine learning will be useful, and possibly integrated in the normal workflow of the future knowledge worker.
The average personal computer will probably be underpowered for that, and the whole point of all these projects is to limit or remove the dependence from the corporate data centre.

@LinuxSocist @jjg @vertigo

In that light, personal HPC, together with personal desktop computing makes total sense.

It's obvious that it's only reasonable to keep projects decoupled and reusable, but I would personally suggest to consider the potential for some periodic loose coordination in the future, to alleviate integration problems later.

@h That kind of sounds like the conversations we have here 😂

@vertigo @LinuxSocist

Knowing about your work @h has influenced my ideas in the long term if not the short-term, and it's very exciting to me to know there are new and interesting applications that could take advantage of the systems I'm working on.

@vertigo 's work has influenced me for a long time, and I greatly appreciate that as well as all the input on nuts-and-bolts stuff :)


@jjg @LinuxSocist@icosahedron.website @h Thanks! I missed this post earlier.

@vertigo I think the very idea that someone might start a new computer from scratch, and that there were other people out there who think about these things came from me stumbling on your project years ago :)

@h @LinuxSocist

@jjg This possible hybrid platform I'm thinking of would have a (Raiden?) cluster as a sort of co-processing unit for heavy duty work that can't be done by the PC alone. Plenty of knowledge work would benefit from assistance, but even tasks that are trivial for a human, like identifying a book by its cover can be helped.

I'm beginning to see a possible parallel between the evolution of mainframe systems towards pcs, and an evolution of hpc systems towards pcs. (minus Google)


@h @jjg @LinuxSocist@icosahedron.website If a future Raiden needs a set of motherboard peripherals (video, ps/2 keyboard and mouse, etc), I can offer that. But, Linux drivers will need to be written for them, which encourages JJG to just use of the shelf RISC-V parts for that anyway.

I hate top sounds like I'm cutting his project off, but it really is not economical to follow Kestrel-3 project anymore.

@vertigo Sorry, I'm not following. You mean that the Kestrel-3 project is in hiatus because the economics of it don't make sense at this time?

@LinuxSocist @jjg

@h @jjg @LinuxSocist@icosahedron.website No. But it may as well be. At the rate JJG is progressing on his project relative to me on mine, he'll have a working RISC-V module running Linux before I even have an integrated processor and I/O chipset. I will still need to write the OS after that. And off have no ecosystem, since I'll be is only user.

I don't anticipate having a working CPU module (with all of 1MB of RAM!) until late next year. Add another year for I/O.

I appreciate your optimism @vertigo, but I might still be soldering LED's by this time next year 😂

@LinuxSocist @h

@h @jjg @LinuxSocist@icosahedron.website The value proposition that Kestrel brings to the table is it is a completely open, as documented as I can make it, computer. At <25 MIPS, it will not compete on progressing speed. At < 8GB, it cannot run half the software people (myself included) wants to run. And it's very expensive for this poor level of performance compared to other competitors.

@vertigo Performance is not the main concern, but freedom, right?. And we have no other personal computer implementer around at this time anyway. I'm personally not too fussed about the wait, or the inability to run Linux.
I'm more awry of things Intel's control of FPGAs, if that restricts our ability to access to reliably fully free machines.
@LinuxSocist @jjg

@h @jjg @LinuxSocist@icosahedron.website Right, focus is on full disclosure of the system. Speed and other things have always been secondary attributes.

@vertigo @LinuxSocist @jjg It's never been understood as an instant solution. All great things take time, that's understood 😃

@h @jjg @LinuxSocist@icosahedron.website Right. I'm just saying it doesn't make sense to wait for the Kestrel if your goal is to finish a project in a reasonable time frame. Using of the shelf parts is a great way to make progress.

The way I see it, what JJG is doing is building the Linux of computers. The Kestrel is more like BSD, where one repo includes everything, not just the CPU. Hope that analogy works.


I've learned to structure my work in parallel, asynchronous ways :)

My ultimate goal is to build open-source (all the way down) supercomputers, which involves a lot of moving parts. So I split the project into three phases to make the most from off-the-shelf while keeping full-custom on the roadmap. Along the way I've moved from Intel to ARM, and now have my sights on RISC-V because openness is essential to the overall project.

Even Linux isn't set in stone :)

@LinuxSocist @h

@jjg Are there any parts from the Raiden project that could be reused by a personal computer project like Vertigo's?

@LinuxSocist @vertigo

@h so far I haven't created any new hardware that isn't specific to the Mark II chassis, but once I'm working on custom modules (or seeking a replacement for the PINE64 Clusterboard interconnect), perhaps?

Semi-related I originally envisioned Raiden (now #rain :) ) to be a co-processor, tethered to a personal computer. I deviated from this for Mark II so it could be a stand-alone system, but Mark III machines are likely to return to that configuration.

@vertigo @LinuxSocist

Show newer
Show newer

@h @LinuxSocist@icosahedron.website @jjg If I relicense, the opportunities for reuse of off the shelf goes up, for sure. I'd have to study Raiden's work to look for such opportunities.

That said, remember, it must fit in iCE40 FPGAs. :)

Show newer

@h @jjg @LinuxSocist@icosahedron.website Maybe Purism would be the closest viable, commercially available provider, but they're x86-64 focused. Going to be providing a laptop from them today, in fact. O:-)

They are doing what they can, and their efforts are to be commended. but if you read their disclosures they are fighting an uphill battle, and Intel will always have the upper hand. I don't know, it really doesn't seem to be the way forward. A temporary tactic at best.

@LinuxSocist @jjg

@h @jjg @LinuxSocist@icosahedron.website Yeah, which is why I'm keeping on keeping on. :-) There'll always be a need for a reference platform for openness. I've even considered relicensing to GPL v3 from MPLv2.

@vertigo @LinuxSocist @jjg I would definitely support that wholeheartedly, should you take that route.

@h @jjg @LinuxSocist@icosahedron.website Meaning relicensing?

Both things, to keep on keeping on, and the potential relicensing. 😃

@LinuxSocist @jjg

@vertigo @linuxsocist @h @jjg HPC eh? I guess this is where I should jump in and provide information about Nix status for RISC-V. :-)

*surf surf*

Apparently GitHub now has projects!

https://github.com/NixOS/nixpkgs/projects/15 is the riscv project for nixpkgs.


> Cross-compiled riscv64 kernel
> RISC-V cross-compilation toolchain
> Initial cross-compilation support for RISC-V
> Build riscv qemu port

So not done yet as a native platform, I guess? But shlevy (who made all of the above) seems to be working hard on making RISC-V working. I've seen traces of their work here and there in nixpkgs, as they de-x86-ify and remove other assumptions from various packages and package infrastructure.
@linuxsocist @vertigo @h @jjg Sounds like https://github.com/shlevy/nixos-riscv-bootstrap is even able to get a NixOS VM image that runs busybox in a RISC-V qemu system.


I hadn't considered going the emulation route but that might be a useful stop-gap to un-block the software dev side of things if it takes too long for me to get a hardware RISC-V compute module together.

Right now I'm plenty busy with other hardware work but something to consider when I wrap that up :)

@h @vertigo @LinuxSocist

@jjg @LinuxSocist@icosahedron.website @h If you use the same FPGA as the dev board, and the same RAM, etc., then that will work fine. Just be aware that pin assignments might be a bit wonky for your needed layout.

I think that's how most FPGA projects evolve. Start with the dev board, then make a custom PCB with the same parts, then iterate.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!