One solution is e-bikes which are getting better every year and will allow you to go quite far without breaking a sweat.
96 karma · joined August 7, 2017
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.
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.
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.
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.
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 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")
// ...
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
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.
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
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.
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.
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
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?