Highlights from FPGA 2020 | Hacker News Reader

Highlights from FPGA 2020

johnwickerson.wordpress.com

93 pointsmatt_d21 comments

> Yann Herklotz‘s paper on “Finding and Understanding Bugs in FPGA Synthesis Tools” described his efforts to find bugs in tools like Quartus, Vivado, and Yosys; his presentation was greeted with an amusing mixture of alarm and pride from the developers of these tools, depending on the respective number of bugs he found in each!

Linked paper has a summary of the bugs found: https://yannherklotz.com/docs/verismith/verismith_paper.pdf

Also from the paper:

> All the bugs mentioned were reported and confirmed by the tool maintainers and vendors. Most of the Yosys bugs were fixed within the day, whereas Xilinx confirmed the bug and intend to “fix this issue in future releases”.

And this is why open source tools are better in the long run.

I remember running a fuzzer on yosys and reporting several bugs that popped up years ago, and Clifford was very prompt and responsive fixing them.

As a hobbyist I have to say: Yosis is just so much more pleasant to use than the commercial tools, even if it were horribly buggy I think I would prefer it.

Is that an apples to apples experience comparison?

I use Quartus primarily in a Makefile, just the way I use Yosys and Nextpnr in a Makefile.

There really isn’t a whole lot of first order difference.

But with Quartus, you get better language support, vastly better timing constraints, and excellent debugging tools.

I recently did the test compiling an identical design from RTL to bitstream for both Yosys/Nextpnr and Quartus, and the speed to completion was very close (though the fill percentage for the Lattice part was much higher.)

Quartus gets a lot of criticism for its GUI/editor, but that’s a product category in which Yosys doesn’t even play.

Yosys seems to me to be quite ripe for a GUI add-on. Its cleanliness and elegance befit the KISS ideology of an OpenSCAD-style IDE.

I honestly don’t see why or how?

It’s a synthesis tool. RTL goes in, logic elements go out. It doesn’t need a GUI just like Synopsys DC doesn’t need a GUI.

If an IDE for RTL design is your thing, you use a generic tool that may or may not have bindings to invoke Yosys from some menu option, just like Eclipse can be used to call GCC.

See https://github.com/rochus-keller/VerilogCreator/blob/master/... for a compatible IDE.

That’s a Verilog IDE that can be used with any backend tool...

It has a built-in configuration for Yosys and some other FOSS tools, but you can also build your own configuration using a scripting language if the backend is not supported yet.

Excerpt/Favorite:

"Sameh Attia‘s paper on “StateMover” (with Vaughn Betz) described a fascinating system for debugging hardware that sits halfway between simulating it and executing it. The advantage of simulation is its flexibility: the designer can inspect (or even change) the contents of every component, and they can run the clock forwards or backwards until they pinpoint the problem in their design. But the disadvantage of simulation is its slowness: simulating a design can take about 100000 times longer than executing it properly. Sameh’s work describes a way to move the entire state of a design back and forth between an FPGA and a software simulator. His proposal is that a design starts running on an FPGA, then at some predetermined trigger point, the clock is stopped and the current state of the FPGA is copied over to the simulator. The designer can then investigate what is going on at this point, and maybe step the clock forwards or backwards a bit, and then they can copy the new state back to the FPGA and carry on running it. The best of both worlds is thus achieved: the fiddly parts of the design can be run in the simulator, and the long, uninteresting parts can be left to the hardware. Myself, I wondered whether this system could form the basis of an exhaustive hardware simulator: one that runs a design in hardware until comes to some sort of ‘branch’ or ‘decision point’, at which point it saves its current state, and executes one of the paths. Later it restores this saved state and executes the other path. Thus, it might be feasible to explore all the possible behaviours of a system."

> Stefan’s paper asks what would happen if we could just stick a direct wire between certain pairs of LUTs, like you can when designing fully-custom hardware. It’s a hypothetical question, of course, because FPGAs don’t actually allow this.

Granted, it's been almost 30 years since I touched an FPGA, but are Long-Lines not a thing anymore? They were a limited resource, but as I recall they did make it possible to make fast long-distance connections.

Do you mean twisted pairs?

I don't think that long lines scaled particularly well with increasing number of LUTs and clock rates. All the black magic voodoo that goes into matching prop delay for resources like that tends to be applied to clock distribution. At least that's how it was a few years ago.

This is more about making fast short-distance connections.

The StateMover concept sounds pretty interesting and is almost like the reverse of the integrated-logic-analyzer approach that the major vendors have adopted in their tooling. I assume that in simulation land that your debug environment is based on timing simulation, which unless they've "fixed" the net name mangling, is not exactly pain-free in its own right.

It has to be post-implementation, but not necessarily a gate-level sim

> Jakub Szefer‘s invited talk on “Thermal and Voltage Side Channels and Attacks in Cloud FPGAs” described a rather nifty side-channel through which secrets could be leaked in the context of cloud-based FPGAs.

I have a feeling, that we are going to find that multi-tenant hardware is a no-go for security. This will have profound implications on the cloud business.

You can already get dedicated, single tenant "cloud" hardware from a variety of vendors.

Even if true, I don’t know if this is as big of a deal as it seems. To me it looks as though a great amount of the value provided by cloud providers today is actually all of the services provided around code, like databases, caches, firewalls, and probably hundreds of other services that are parallel to compute tasks and should be able to handle multi-tenant workloads safely.

Even if multi-tenant arbitrary code execution proves to have unfixable side channel vulnerabilities:

- You are obviously still not allowed to go and steal other people’s data. Anyone providing VMs could work towards potentially both mitigating and detecting side-channel attacks.

- Not every workload is the same level of sensitivity; some software may need almost no secrecy at all. Sure, you definitely can’t be handling user data or credit card info. But, OTOH, with newer managed stacks and APIs like Stripe, you might not even be doing that on your own backend at all. You may not even have your own backend.

- You can, of course, get single-tenant VMs from some cloud providers. It will be less flexible but it’s already necessary for some workloads for compliance reasons.

It’s also worth considering the severity of side channel exploits; they certainly work but practical usable attacks are probably not going to happen for every new side-channel exploit.

Does anyone know if these presentations were recorded and videos will be posted?

They weren’t recorded, no.

Reply on news.ycombinator.com