ekiwi's comments

One solution is e-bikes which are getting better every year and will allow you to go quite far without breaking a sweat.

The 32-bit aligned instruction assumption is probably baked into their low-level caches, branch predictors etc. That might mean much more significant work for switching to 16-bit instructions than they are willing to do.

They verified the protocol, not the actual implementation: https://github.com/rosenpass/rosenpass#security-analysis

This is still a pretty neat result! End-to-end proofs from high level protocol to low level implementation are mostly still a research topic.

My biggest question after looking at the readme: What happens if your computer crashes while dura is making a commit? Can it corrupt your local git repository? From my own experience, git is not crash safe, i.e., it can leave the .git directory in an inconsistent state if the computer crashes during certain git operations.

> nuclear waste is not waste

There is a lot more to nuclear waste than just the fuel rods. Lots of materials that are either used by workers at the plant or part of the plant become radio active and can no longer go to a regular landfill of other trash processing facilities. That is why some energy companies are trying to default rather than pay for decommissioning plants once they have reached the maximum age that they were constructed for.

> if the two of them don't decide to add their own proprietary "extensions" to the language.

icc has always had its own dialect of C++, which in practice means that there is "C++" code that only compiles on icc but is rejected by clang++ and g++. With Intel switching to the clang frontend, I would hope that their interpretation of C++ will become more, not less, standard conform.

> At best you can do the same with one reduced canonical simplified verilog source-to-source translation.

Parsing Verilog and generating valid Verilog is fairly difficult. If you want to stay with Verilog, the most realistic alternative to firrtl right now is the RTL-IL representation used inside of yosys.

> at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.

Canonicalized LoFirrtl (i.e., the representation the compiler lowers Chisel to) is essentially SSA (single static assignment) which encodes a dataflow DAG. So on a per module level, firrtl does represent the circuit as a graph.

What you might be talking about is the fact that this graph isn't global. Having a global circuit graph could make some analyses easier, but it might require essentially in-lining the whole circuit which is something a lot of designers are opposed to. Even small optimizations like removing unused pins from internal modules are often times opposed.

Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt As you can see they did not decide to go with a global graph based IR and instead opted to just represent local data-flow graphs as SSA.

> Access to any global variable should always occur direct from memory.

What if your function takes a pointer that might be pointing to a global variable? Does that mean that all accesses through a pointer are now excempt from optimization unless the compiler can prove that the pointer will never point to a global variable?

> Chisel is therefore it's "synthesizable subset".

Chisel is not synthesizing Scala. It is just a library implemented in Scala that allows you to create a data structure that describes a circuit.

Something like:

  circuit = Circuit("test")
  module = circuit.module("test")
  in0 = module.input("in0")
  // ...

The one thing Chisel adds on top of an Object hierarchy that describes a circuit is what PL people normally call "syntactic sugar". I.e., Chisel makes constructing this circuit object look more like a Verilog circuit by taking advantage of some nice Scala features. However, in the background, we are just constructing a data structure that represents a circuit, just like in a GUI library you might construct a data structure that describes your widget hierarchy. Chisel is not High Level Synthesis.

Chisel imho solves the "synthesizable subset" problem quite elegantly: All Chisel constructs are simple, synthesizable circuit elements and boolean functions (+ functions on fixed size integers that can be converted into boolean functions). All automation happens in the meta-language which in this case is Scala. Chisel was always intended for synthesizable hardware!

Chisel is not HLS. It is a Scala library that lets you generate circuits on an RTL abstraction level. That means that you explicitly define every state element like registers and memories. But you can generate N registers inside a loop (or a map/foreach) instead of only 1 at a time. In HLS the compiler needs to somehow infer your registers and memories.

That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since all your testing infrastructure is setup for testing assembly code and that is "what we have always been doing".

In order to catch verification up to modern Hardware Construction Languages [0] we need more powerful verification libraries that can allow us to build tests that can automatically adapt to the parameters that were supplied to the hardware generator. There are different groups working on this right now. The jury is still out on how to best solver the "verification gap". In case you are interested:

- https://github.com/chiselverify/chiselverify

- https://github.com/leonardt/fault

- https://github.com/ucb-bar/chisel-testers2/

I am probably missing some approaches from the nmigen world that I am not familiar with. You can always write cocotb [1] tests in python, but I am not sure if they can directly interface with nmigen generators to adapt to their parameterization.

[0] besides Chisel, there is also https://github.com/nmigen/nmigen and https://github.com/SpinalHDL/SpinalHDL

[1] https://github.com/cocotb/cocotb

Did you see the work being done on CIRCT? https://github.com/llvm/circt

I remember one of the reasons you did not want to use firrtl was that its compiler is implemented in Scala and thus hard to integrate into other projexts. CIRCT will solve that problem by providing a firrtl compiler implemented in C++. Other languages like Verilog/VHDL and new high level languages for HLS-like designs are also on the todo list.

It was in fact the EdgeTPU (which is different from the TPU used in data centers).

The talk from a google engineer can be found on youtube: https://www.youtube.com/watch?v=x85342Cny8c Please note that they were using a version of Chisel from 5+ years ago and many things have changed since then. It is still true though that Chisel can be hard to learn for typical hardware engineers, which is why it may be best suited for small and highly dedicated teams rather then large hardware companies.

[EDIT] Here is a talk from a solo-developer using the latest version of Chisel: https://www.youtube.com/watch?v=Wst8IoYRWKo

I think the hardest problem is contributing changes back upstream. With hardware, people are a lot more paranoid about introducing new bugs and I feel like that sometimes makes collaboration a lot more difficult.

Sounds like nmigen might be a good open source successor to the project that you describe: https://github.com/nmigen/nmigen There are lots of open-source (n)migen components available through the litex framework: https://github.com/enjoy-digital/litex

If you hit the Windows key on Gnome 3, you can type the name of a program, file or system setting and it will generally find it.

Glacial was one of the entries for the 2018 RISC-V SoftCPU Contest, but I think it wasn't ready by the deadline. If you look at the winners there was another 8-bit CPU with a RISC-V interpreter, SERV, VexRiscv but also Reindeer which seems like a more balanced implementation: https://riscv.org/blog/2018/12/risc-v-softcpu-contest-highli...

How do you deal with structured formats, like XML? In JQF you would just write a XML generator (see their examples). If you just use the "sequence of bytes" approach as AFL does, then a lot of your inputs might be immediately rejected by the parser.

If you are interested in fuzzing your Java code, you should also have a look at the JQF project which directly integrates with junit tests: https://github.com/rohanpadhye/JQF

This is the latest paper on BOOM: http://people.eecs.berkeley.edu/~krste/papers/SonicBOOM-CARR...

It has some comparisons so you can judge for yourself. Of course, since this is a project driven by only 2-3 grad students it isn't completely fleshed out. However, you would assume that if the ISA just wasn't suitable for high performance implementations that a project like BOOM would have uncovered that by now.