So what's state-of-the-art in open-source #FPGA?

Is #IceStorm where it's at? I'm interested in synthesizing cpu cores which I think puts me in the area of large-ish fabric devices but again I stopped looking for a few months and now I feel like I have no idea what to expect :)

@vertigo @h @cstanhope

@jjg @h @cstanhope reverse engineering work with Xilinx artix 7 is ongoing. Otherwise, the state-of-the-art is the Yosys tool chain for the iCE40HX family.

@jjg @h @cstanhope ISTR there was a recent announcement at a recent C3 convention to this effect, but I am not fully aware of what that announcement was about. Might want to check up the itinerary and videos from the latest C3 conference.

@vertigo I'm still not clear what's the situation regarding RISC-V and FPGA development, what's at the intersection of these two important building blocks. @jjg @cstanhope


@h @jjg @cstanhope Can you be more specific?

Right now, the "official" RISC-V reference implementation, Rocket, is still ASIC-optimized. FPGA-based RISC-V cores tend to be home-grown things these days.

You can still synthesize Rocket on an FPGA, but because it's optimized for ASICs, it needs a rather large FPGA to do so, since it's investing individual LUTs to things that can be only a few transistors in an ASIC.

· · Web · 0 · 0 · 1

@cstanhope @jjg @h PicoRV32 is perhaps the most popular FPGA-optimized RISC-V core available, hands down.

To this day, my own KCP53000 core is *still* the only 64-bit FPGA-optimized core I'm aware of.

Both have their limitations, however; neither design can run Linux, for example.

I hope that my successor design (KCP53010 -- still vaporware!) will remedy some of them (it should be able to run Linux if it's ported), but it still won't be as complete or as fast as Rocket.

@vertigo What I mean is that the current state of affairs makes every industrially-made CPU suspectful. Especially those made in countries with governments known for spying on citizens wholesale, who attempted to build the Clipper chip in the past.
I'm wondering how far we can go building these systems really from scratch. We still depend on Xilinx or Altera/Intel at some point anyway.
I'm curious about your point of view on these matters.

@jjg @cstanhope

@h @cstanhope @jjg @vertigo It's difficult because as far as I know producing CPUs at anything like a sane price point still requires a serious amount of capital. With major efforts it can be possible to make individual transistors, like Jeri Ellsworth did with a hacked microwave, but I don't think it would be possible to reliably make CPUs that way.

I know, and I agree. But the difficulty of the enterprise never deterred RMS when he started. I think we're at the beginning of a new crossroads of similar long term importance.

@vertigo @jjg @cstanhope

@h @cstanhope @jjg @vertigo I think you're probably right about that. If you pay attention to the relevant conferences it looks like the trend is going to be that much of what we think of today as systems level software is going to get baked into the hardware so that it's not modifiable except by throwing the gadget away and buying the next generation. It's a consequence of reaching the limits of transistor miniaturization on silicon wafers.

I also expect that Intel won't learn much from ME and will instead just embed the same functionality into the CPU rather than a separate chip, as AMD does. Hardware CPU backdoors will probably continue to be a problem.

@bob @vertigo @jjg @cstanhope I agree. And this is precisely part of the reason why the work of guys like @vertigo and @jjg is so important.

@bob @jjg @cstanhope @h Wasn't there someone looking to make 10um or 8um feature-sized semiconductors using garage-accessible equipment not long ago? If so, and once you're familiar with the characteristics of the transistors at those sizes, you can definitely at least make a Z80 or 6502 equivalent CPU.

@h @cstanhope @jjg @bob You can also make a TTA engine to emulate a larger CPU as well; e.g., a 68000 or RISC-V processor could easily be made this way, but you'll pay in clock cycles.

@vertigo @jjg @cstanhope @h There's also the Qubes approach of layering virtual machines on top of hardware which is known to probably be bad. The idea being that even if data can be exfiltraded all the adversary gets is cyphertext. But I'm not entirely convinced that this is a viable way to go.

@bob @h @cstanhope @jjg That certainly will never fly in production environments. The computing power necessary to reduce signal-to-noise ratio for side-channels takes away from what you'd invest normally in servicing production traffic.

@vertigo @bob @h @cstanhope fun thread :)

My motivation is threefold:

1. Learn how to actually build stuff with FPGA and start with open tools of at all possible
2. Design a module for RAIN that can be used to provide application-specific logic, acceleration and other experimental stuff along side the traditional processor modules

3. I’ve been noodling on the idea of a fully-dynamic hardware parallel machine for awhile and curious how possible it might be to realize that using contemporary commodity hardware

@cstanhope @bob @vertigo

@jjg Acceleration as in...? Parallelisation and concurrent programming? Video graphics acceleration? Number crunching on high performance computing?

@cstanhope @bob @vertigo

@jjg This is amazing news! Tangentialy related: I'm trying to see how hard it would be to build a REBOL interpreter in a common assembler (similar to the way Forths are often built). The main reason is I would like my work-in-progress hypermedia engine to eventually run on your free computer architecture and on @vertigo's as well.
@bob @cstanhope

@h @cstanhope @bob @vertigo I would *love* to have something as cool looking as your engine running on #rainpsc :)

@cstanhope I had expected to write a Lisp/Forth/Rebol-like language on top of Go, so I could take advantage of its magnificent cross-compiler, but seeing that RISC-V is not one of Go's target architectures (mainly amd64 and ARM were of interest until now) that it's making me rethink the whole language layer thing. @bob @vertigo @jjg

@h @vertigo @bob @cstanhope I have some weird ideas about using WebAssembly if that helps you at all :)

@jjg Webassembly feels a bit alien to me at this point, but I'll eventually get acquainted. It's possible that there won't be any other better intermediate assembler available ever. Current implementations may be green, but even if it's shite today, there's no doubt that it will be the most ubiquitous deploymeent of an assembly machine ever. Today that place is probably taken by Ethereum's EVM, but I think I heard they're dropping that crap and switching to WA too. @cstanhope @bob @vertigo

@h @vertigo @bob @cstanhope I never thought I’d consider using WA, especially for HPC work, but I got some ideas after reading an article about Mozilla’s optimizations for it.

More info about those ideas in an upcoming blog post :)

@jjg Please cc me when you post, I'm definitely interested. Also moving to start a blog of my own soon. I have enough bits working already that it makes sense to start some new interesting discussions. I don't mean to coordinate too much, but discussing some loose interfaces to ensure that my stuff works on your (jjjg's and vertigo') gear would be important to me personally. And hopefully I'll be able to explain why and how.
Soon! @cstanhope @bob @vertigo

@h @vertigo @bob @cstanhope will do, and when you get your blog going be sure to let us know !

Show newer

@h @jjg @bob @cstanhope I'm definitely interested in the REBOL environment, even without the hypermedia engine.

Although I'm having a blast with DX-Forth, REBOL would be somewhat more productive for folks who just wanna get stuff done.

@vertigo I think REBOL is probably a little bit more complex to get right and complete with its standard library but it should pay off in the long run because ..... really, it's just better AND easier than Javascript.

@jjg @bob @cstanhope

@h @jjg @cstanhope I'm not sure I'm qualified to answer these questions, as I don't work in infosec nor have experience in it.

That said, I do know that:

- Rocket core, KCP53000, and PicoRV32 are *not* susceptible to either Meltdown nor Spectre
- BOOM core, as it currently stands, *IS* susceptible to Spectre, but not to Meltdown.

@cstanhope @jjg @h
Basically, anything that provides speculative execution across a protection boundary and which has caches and which lets you access an accurate timer or counter will be prone to Spectre. Spectre isn't dependent on ISA, nor really on specific microarchitecture.

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!