
Highlights from FPGA 2020 - matt_d
https://johnwickerson.wordpress.com/2020/02/27/highlights-from-fpga-2020/
======
ohazi
> 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](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.

~~~
jeremysalwen
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.

~~~
swiley
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.

~~~
tverbeure
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.

~~~
Rochus
See [https://github.com/rochus-
keller/VerilogCreator/blob/master/...](https://github.com/rochus-
keller/VerilogCreator/blob/master/README.md) for a compatible IDE.

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

~~~
Rochus
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.

------
peter_d_sherman
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."

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

~~~
bisrig
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.

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

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

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

~~~
jchw
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.

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

~~~
wicko3
They weren’t recorded, no.

