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@icosahedron.website

@h @LinuxSocist@icosahedron.website @vertigo is love to have one of those 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 one way or another 😁

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

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

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

@vertigo @h @LinuxSocist@icosahedron.website 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 @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@icosahedron.website 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.

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

@h @LinuxSocist @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 @jjg @LinuxSocist@icosahedron.website 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@icosahedron.website @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 @jjg @LinuxSocist 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@icosahedron.website @jjg

@h @jjg @LinuxSocist 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.

@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@icosahedron.website @jjg

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

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

@h @jjg @LinuxSocist 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@icosahedron.website @h

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

@LinuxSocist@icosahedron.website @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 :) ) 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@icosahedron.website

@jjg Ok I will have to read more about Mark III then.

And following
@vertigo 's analogy about Kestrel-3 being a BSD (all in a box), and other hardware projects being more like a Linux distro...

You guys could easily become "upstream" for guys like Purism.

@h @vertigo @jjg Speaking about BSD distros I will only choose TrueOS which seems to be supported by a company (Ixsystem) the main problem of some this distros is the lack of the developers and programs in the other hand BSD are rock solid operarting systems.

@jjg @LinuxSocist @h A standard interconnect, honestly, is probably the biggest opportunity for collaboration here, since we're both going to need peripherals. :-)

@vertigo yes! Interconnect is currently the weakest link in Mark II (it's just gig ethernet :) )

@h @LinuxSocist@icosahedron.website

@h @LinuxSocist @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. :)


Something we've discussed in the past is using , and this is something I've really warmed-up to lately.

I've even seen a project that implements a microkernel runtime for it: github.com/nebulet/nebulet

The idea of ditching Linux in favor of something like this on the compute notes is interesting, especially if instead of CPU+kernel it could be pure hardware? :)

@LinuxSocist@icosahedron.website @h

@jjg There's ample precedent of stack machines (FORTH machines in hardware) not at all unlike WASM's design, it's not a crazy idea at all.

@LinuxSocist@icosahedron.website @vertigo


Maybe I should be starting here instead of chasing RISC-V? :)

@LinuxSocist@icosahedron.website @h

@jjg Well, RISC-V will eventually have plenty of software that virtualises WASM. Your idea is more "unique", if the expression makes sense.

@LinuxSocist@icosahedron.website @vertigo

@h @LinuxSocist @jjg The nice thing about TileLink is is independent of CPU. If it helps, you could start with RISC-V, get Linux running, then maybe add wasm coprocessing later on the same interconnect.


I need to learn more about TileLink :)

@LinuxSocist@icosahedron.website @h

@h damn folks we have a lot of work to do 😀 💪

@vertigo @LinuxSocist@icosahedron.website

@h Looks like TileLink is chip-level focused so I'll probably need something secondary like Infiniband, etc. to scale-out, but still a very cool bit of tech.

@vertigo @LinuxSocist@icosahedron.website

@jjg I don't know if there are any patent minefields on the Infiniband front, some due diligence is due I think. @LinuxSocist@icosahedron.website @vertigo

@h yeah I'm not locked-in to Infiniband itself, just something like it (scalable, suitable for off-board physical connections, RDMA, etc.)

@vertigo @LinuxSocist@icosahedron.website

@vertigo RapidIO I've looked at (at your recommendation in the past). Definately seems interesting and along the lines I'm lookin.
@h @LinuxSocist@icosahedron.website

@jjg Seeing that HPC is expressly considered as an area of application of RapidIO, there may be useful experiences to learn from out there in the industry

@LinuxSocist@icosahedron.website @vertigo

@jjg @LinuxSocist @h Yeah. Earlier, back when I was using Wishbone bus, I was worried about how I'd adapt RapidIO to it.

But, after reading about TileLink and making the decision to use it for the front-side interconnect to the CPU, bridging to RapidIO is now much easier. It's still not an effortless task, mind you. But it is significantly easier to pull off because there's much reduced impedance mismatch between the two approaches.

@jjg @LinuxSocist @h The only reason I'm building up ByteLink (which should really be called NybbleLink -- whoops) is because RapidIO is overkill for what I needed to solve a specific problem.

Sifive ostensibly has their own off-chip adaptation of TileLink as well. Not sure what it's called though, and I've not ready any documentation on it. I first learned of it in a slide deck at a RISC-V workshop.

@jjg @LinuxSocist @h TileLink is a message-passing inerconnect for modules on-chip, yes. However, because it is message passing, it is relaively easy to serialize ino a packet-switched interconnect fairly easily. See chiselapp.com/user/kc5tja/repo for one such mapping, which I was going to use to bridge the two FPGAs of the Kestrel-3 together.


ooooh neat :)

@h @LinuxSocist@icosahedron.website

@h yes, also the idea of using a language that is recognized and has tool support attractive to developers outside of systems programmers/hpc developers is very attractive to my mission of making hpc accessible.

@vertigo @LinuxSocist@icosahedron.website

@jjg The more I think about it, the more I like it. @LinuxSocist@icosahedron.website @vertigo


What got me considering it is some clever work being done at Mozilla to automatically parallelize javascript and ( parallelization being one of the hardest things for developers to do well, and one of the most common bottlenecks to making the most out of supercomputers)

@vertigo @LinuxSocist@icosahedron.website

@jjg @LinuxSocist @h So should I work on a GPLv3 wasm and Forth CPU with a TileLink interconnect? O:-)

@vertigo Can a POSIX-like kernel be built on top of that, so we also get to build a personal computer from the same basic parts? @LinuxSocist@icosahedron.website @jjg


Damn, that would be a leap forward but I the more I think about it the more sense it makes.

The hang-up for me would be making "traditional" HPC applications run on it (I'm thinking MPI & friends) but I could but then there's Emscripten... 🤔

@h @LinuxSocist@icosahedron.website

@jjg How hard would it be to implement the MPI network protocol in FORTH targetting the WWASM architecture?
@LinuxSocist@icosahedron.website @vertigo

@h Unsure, but I assumed I'd be digging into wrenching on it because at some point I'd be using an unsupported CPU and/or interconnect anyway :)

@vertigo @LinuxSocist@icosahedron.website

@h @LinuxSocist @jjg I don't know anything about MPI or wasm details. I honestly couldn't judge. It cannot imagine it'd be any harder than a plain C implementation though, especially if done right. Worst case, compile C code to stack machine code, take the performance hit, then hand optimize where profiling shows hotspots.

Sign in to participate in the conversation

A Fediverse instance for people interested in cooperative and collective projects.