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.
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.
@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.
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.
@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.
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 :)
@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.
Something we've discussed in the past is using #wasm, and this is something I've really warmed-up to lately.
I've even seen a project that implements a microkernel runtime for it: https://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? :)
@jjg Tilelink spec 1.7 (draft) as PDF
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.
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 http://chiselapp.com/user/kc5tja/repository/kestrel-3/wiki/ByteLink for one such mapping, which I was going to use to bridge the two FPGAs of the Kestrel-3 together.
@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.
A Fediverse instance for people interested in cooperative and collective projects.