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

Is 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 @vertigo @h @cstanhope Hi again, at the moment I don't know so much about IceStorm, what is it about ? 🤔

@neomoevius open-source toolchain for FPGA:

Last I checked it was the only thing like it, but it was also targeting a specific device and I'm not sure if that's changed since the last time I did a deep dive.

@vertigo @h @cstanhope

@jjg The two biggest providers are Xilinx (with 51% of the market) and Altera. Xilinx appears to has made a killing with their focus on the ARM ecosystem. Intel bought Altera a couple of years ago, for $16 billion, so they're the second largest or the largest FPGA manufacturer, depending how you look at it. The circle is getting narrower. If you're aiming to support ARM due to their energy efficiency for example, Xilinx is a better way to go.

@cstanhope @vertigo @neomoevius


As I understand it, neither of them offer an open-source toolchain, correct?

@neomoevius @vertigo @cstanhope

@jjg Xilinx offers a proprietary system that is based on FOSS, including a development environment and a system that facilitates code reuse (greatly helped by the ubiquity of Android on ARM).

So, whilst the tooling is not really open source (to my knowledge, which may be outdated), some people find it very useful to make open source things.
I haven't looked into Intel stuff, but it's well documented for what I see

@cstanhope @vertigo @neomoevius

@neomoevius I have no idea if Intel are playing nice with open source FPGA. They may well be, as they are being very decent on the GPU front, and they're playing catch up with ARM on a few fronts. But as you obviously know, Intel or any corporation their size is a cause for concern given what we see in the news.

@vertigo @cstanhope @jjg



My 5 minutes worth of research indicates that has the capability of providing an open-source toolkit (now I just need to figure out if what I want to do will fit within the it supports :) )

@cstanhope @vertigo @neomoevius

@jjg @h @cstanhope @vertigo Let me see but this tool IceStorm will improve GPU acceleration in someway or what improvements would be in graphics acceleration ?. Just curious I don't know so much ..... 🤔

@neomoevius fpga has many applications, my interest is in producing application-specific logic and experimental cpu architectures.

@h @cstanhope @vertigo

@jjg @cstanhope Apart from Ice there's things like TinyFPGA, and a whole array of simple Arduino-related tools, but those little platforms may not be a good match for the applications I assume you'll be working on. You may also want to take a look at projects on github like:
and elsewhere:



Yeah I'm not sure exactly what I need, I probably just need to block some time to do the homework.

I might pick one of those ICEsticks up just to go through the motions and see how much I enjoy the work. I picked up some other FPGA dev board a year or so ago but I've never had the time/patients to get the dev tools setup.

This 20 page PDF that gets you a open-source soup-to-nuts CPU running forth is my kind of carrot on a stick though :)

@vertigo @cstanhope

@jjg Yeah, becoming a professional of some of those mammoth tools feel like converting to a mainstream religion to me too. I'm only looking into this now because the kind of work I'm doing is getting closer to the iron all the time. But I'm really more interested in building excellent GUI systems. I just have to know what are the tools that may make the ends more achievable.

@cstanhope @vertigo

My interest in hardware is mainly to see what can we do to bring truly, wholly free systems closer to the mainstream.

The state of affairs is incredibly anti-ethical and repugnant to me.

Read-only open systems aren't really free if people can't use them to make the best machine the machine is capable of becoming.

There's no good reason meta-machines must be read-only, or write-with-caveats-only. It's just a neoliberal deviation that too many have accepted as the new normal.

There's no good reason for being forced to produce an ellaborate OpenGL based compositor and window manager if you want to make some things move on screen, or just have some windows and pushbuttons that actually work.
There's no good reason for having a massive dependency on web browsers that are de facto controlled by the hands of three corporations. One of them, Mozilla, may be benign for the most part, but that's not sufficient justification.

@h Mmm.

So much of what we actually want to do with computers seems to be 'small jobs' - store little bits of very personal and very important data - but we have to use 'big systems' to do it.

Feels like a mismatch to me. Why can't we have small systems that we can use for small jobs and then build bigger systems OUT of small systems?

I don't know what the smallest SAFE system is though.

I don't want a tiny system that can corrupt its RAM or hard drive if I breathe wrong.

@natecull @h The safest system is any system not attached to a network. A lot of what we use computers for can be satisfied using store-and-forward networks (e.g., BBSes) with intermittent connectivity.

About the only exceptions I can think of presently are streaming audio/video.

@vertigo Some ways to architect systems exist that could make personal computing less repugnant.

For instance, a "front-computer" as a sort of kerberos that grants or rejects access to the main computer. Think the way baseband is your gatekeeper to the outside world on a mobile device, but in the other direction.

There's no good reason this couldn't be built in modern devices. The only reason is that marketers, liberals, and fascists wouldn't get to read about your laundry.

@h This architecture is known as the "egg shell" approach to security, and for the longest time it has worked well. However, recent advancements in key breaking, side-channel attacks, etc. are showing that it's no longer as effective as it once was.

Every breach made recently has been through a compromise in the egg shell.

@h Don't get me wrong; I think it's a great first step, and clearly vastly superior to nothing at all. But if you're dealing with credit card numbers and/or medical information, it's not enough.

@vertigo I agree on both counts. Still not enough, but possibly a good start.

@vertigo @jjg Re. alt-REBOL impl. i think I'm going to write a bareboes interpreter in Go first anyway. That will probably be a good learning experience targetting known archs first. Instead of attempting to implement it on RISC-V with extra complexity. It may be useful to bootstrap later if the interr̀eter itself is wrotten in Rebol too.

@jjg @vertigo Sorry for the typos, currently on the road.

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

@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 :)

@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

Show more

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

Show more

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

@jjg @vertigo I read through the thread. I agree with Vertigo's assessment. Yosys is the state-of-the-art FLOSS toolchain. You can do a lot without ever touching a board. Of course, getting your hands on hardware can be a big part of the fun, so don't let me stop you.

If you do find yourself wanting to target hardware not supported by the FLOSS tools, I find that dedicating a virtual machine to the Xilinx or Altera tools into virtual machines works best. I use Vagrant at work to help with this.

@vertigo @jjg *sigh* typos... Hopefully it was clear what I meant.

@cstanhope @jjg Since it's always easier to consolidate multiple separate FPGAs onto a single, larger, FPGA, it's actually an advantage that I'm working with Yosys to start with.

I have an Altera/Terasic DE-1 on my desk that I'd like to work with as well, and getting Kestrel-3 running on the Cyclone II part it has should be much easier once it's known working on the two iCE40s first.

If I'd done the Cyclone II first, I'd have to figure out where to cleave the design, if it was at all possible.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!