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.
@jjg @LinuxSocist @h @vertigo I've seen a 68000 using an FPGA. A bit of googling revealed this one: https://sites.google.com/site/olivier2smet2/hp_projects/hp98x6/fpga-hp98x6
There also seems to be a bunch of soft cores implementing 8-bit CPU's as well if you want something simpler.
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.
@jjg @h @LinuxSocist 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.
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.
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 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 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.
@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 :)
@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.
@h @jjg @LinuxSocist 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.
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 :)
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.