[cushychicken]

the productivity gains we might have had on the design side were more than lost on the verification side

This makes sense. Without a complementary lift to verification capability, a lot of the design side wins don't gain you much.

[aDfbrtVt]

I'm very surprised by the reported cost to verification. One of the major reasons to move to a high level synthesis design strategy is to ensure equivalence between your models and RTL.

I have experience with C++ HLS and it has enabled massive reductions in verification time.

[ekiwi]

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

[Rochus]

Meanwhile there are surprisingly many programming languages with a "synthesizable subset" meant to "replace Verilog". From my point of view it would make more sense to look for a dedicated language, which does not have the uncertainty of synthesizability (because the language was originally intended for something completely different), and which does not aim at the most general case of digital design, but e.g. only RTL and behavioral level for synchronous circuits. This might be an example: https://people.inf.ethz.ch/wirth/Lola/index.html.

[ekiwi]

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!

[Rochus]

Scala is a general purpose programming language. Chisel is therefore it's "synthesizable subset". To use Chisel you need to know Scala as well as the HW design specific constructs Chisel offers.

EDIT: and Scala or the functional programming paradigm are not something design or verifications engineers are usually familiar with, which was apparently also a major issue in the Google project according to the referenced talk (quote: "frankly, most hardware engineers don't really get passed this yellow [Chisel learning] curve")

[ekiwi]

> 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.

[aDfbrtVt]

Thanks for clarifying, I was under the (false) impression that Chisel was used for HLS. I know of a few companies working with SystemC and UVM-ML to accelerate verification. Having closer ties between design and verif becomes absolutely essential when you’re flow is accelerated.

I’ve personally used HLS C++, GTest and UVM. It’s pretty effective but there’s definitely room for improvement.