5 ms·

as much as it pains to say me, but IMO its a wasted effort. we don't need new design languages. VHDL/Verilog "pain points" as RTL are tiny and don't require sol

as much as it pains to say me, but IMO its a wasted effort. we don't need new design languages. VHDL/Verilog "pain points" as RTL are tiny and don't require solving, we pretty much figured out design. Verification, on the other hand, is still an evolving (now stagnating) mess that needs inputs. The biggest offender on that project list is FIRRTL. Cleary outgrew as someone's university work of "hey, lets do IR, but for RTL" without knowing anything of the industry, tools, etc. At best you can do the same with one reduced canonical simplified verilog source-to-source translation. 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.

GregarianChild 5y ago
Chisel's being hooked into the Java / Scala tool chain give makes setting up automated verification pipelines much easier: - You can use SBT or MVM to pull in dependencies - You can wrap up designs as .jar files - Powerful testing tools like QuickCheck come ready made None of the above is rocket science, but simply by being there things become easier. without knowing anything of the industry, tools, It's pretty difficult for a student to find out about what is actually used in industry. The semi industry's secrecy doesn't help. But software and hardware people really don't even have a shared language, and misunderstand each other's abilities and pain points. The very term "verification" is understood quite differently between the different communities.
ekiwi 5y 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 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.

GregarianChild 5y ago

Chisel's being hooked into the Java / Scala tool chain give makes setting up automated verification pipelines much easier: - You can use SBT or MVM to pull in dependencies - You can wrap up designs as .jar files - Powerful testing tools like QuickCheck come ready made None of the above is rocket science, but simply by being there things become easier. without knowing anything of the industry, tools, It's pretty difficult for a student to find out about what is actually used in industry. The semi industry's secrecy doesn't help. But software and hardware people really don't even have a shared language, and misunderstand each other's abilities and pain points. The very term "verification" is understood quite differently between the different communities.

ekiwi 5y 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 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.