ekiwi
Joined 9 years ago
Karma
96
Submissions
37
Member since
Aug 7
Recent submissions
Comment · 2 years ago
One solution is e-bikes which are getting better every year and will allow you to go quite far without breaking a sweat.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 4 years ago
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.
Comment · 5 years ago
> 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.
Comment · 5 years ago
> 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.
Comment · 5 years ago
> 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.
Comment · 5 years ago
> 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?
Comment · 5 years ago
> 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")
// ...
Comment · 5 years ago
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!
Comment · 5 years ago
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
Comment · 5 years ago
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.
Comment · 5 years ago
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
Comment · 5 years ago
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.
Comment · 5 years ago
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