ekiwi

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")
  // ...

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.

It used to be you could email a patch to someone and that patch would get reviewed and committed.

Yes, but 1990 is also when this study came out: https://ftp.cs.wisc.edu/par-distr-sys/technical_papers/fuzz....

They find that a lot of UNIX tools could be easily crashed by generating random inputs. The quality of our most popular open source software has dramatically improved over the last 30 years.

You might be interested in this work which integrates a programmable fabric directly with a MIPS core in order to speed up inner loops: http://brass.cs.berkeley.edu/garp.html

You also have to keep in mind that modern flows can already automatically place more area/power efficient but slower transistors on the non-critical paths. Thus signals can get balanced and the wasted area/performance is not as big as one might think.

The problem with delay slots is that their optimal size is somewhat tied to the particular micro-architecture. I.e., different MIPS CPU implementations would have different optimal branch delay slot sizes. This doesn't matter too much if your compiler is allowed to optimize for your particular implementation, but we are still mostly shipping binaries and thus you would have to make trade-offs for portability reasons.

I thought Berkeley's BOOM is way more advanced implementation of RISCV than VexRiscV and it is written in Chisel3.

It is a lot more advanced and thus harder to get started with than VexRiscV.

BOOM does not look like most effective in terms of LUTs utilisation core.

So the problem is also that the BOOM design is targeted at ASICs. The developers do not generally synthesize BOOM for FPGA. Only as a FireSim project which is using FPGAs to do fast simulations in order to get more accurate performance figures by running real world benchmarks (multiple MHz of target frequency). None of the developers are interested in using BOOM as a computer on an FPGA and thus no one has provided support for that.

Another thing I also disliked in Chisel3 is dependancy on new intermediate representation of hardware (FIRRTL) which adds one more layer of abstraction and compilation.

I really enjoy working with firrtl. It is generally easy to inspect and quite human readable. With firrtl you can:

- automatically add coverage instrumentation:

  - for fuzzing: https://github.com/ekiwi/rfuzz/tree/master/instrumentation/src/rfuzz

  - for simulator independent coverage [wip]: https://github.com/freechipsproject/treadle/pull/263

- for ASIC development it is important to be able to replace all memories in your design with appropriate designs specific to the technology you target: https://chipyard.readthedocs.io/en/latest/Tools/Barstools.ht...

Adam's thesis has some more examples on what you can do with firrtl: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-...

There also might soon be a second implementation of a firrtl to Verilog compiler if you prefer C++ over Scala: https://github.com/llvm/circt

I think in general Chisel has more people working on it. However, most people using Chisel are targeting ASICs, thus Spinal HDL wins when it comes to supporting features that are important to FPGAs. Chisel also hasn't anything close to the awesome VexRiscV core which was developed for FPGAs. The most developed cores written in Chisel are much bigger and more complex as they target ASICs. See the chipyard repository which tries to lower the learning curve a little bit : https://github.com/ucb-bar/chipyard/

In case you have a FOMU and are interested in exploring Chisel, I recently added a simple Blink example that should help people get started: https://github.com/im-tomu/fomu-workshop/blob/master/chisel/...

It seems like the real challenge would not be the translation of individual code snippets to a newer programming language, but more about adapting the code base to a different library eco-system. For example you would have to understand the exact behavior of the Cobol and Java standard libraries if you wanted to correctly translate code between the two languages.

You might also have implicit dependencies in the legacy code on the schema of some external database, all of which would need to be taken into account when migrating.

Also, tests might be missing, so how do you even know that your migration was successful?

If you want to find the source code and some information on how to build and run it, you should check out their new website: https://boom-core.org/

Wouldn't you also need a way of storing information (preferably an unlimited amount of information) for Skylines to be turing complete? How would you implement the tape of the turing machine?