Yosys is missing a FIRRTL frontend

[boqwxp]

Yosys is currently missing a FIRRTL frontend. Verilog is not ideal as an interchange format, and nobody seems to be using BLIF much these days. It is not necessary to support everything in FIRRTL; a frontend for just "lowered FIRRTL" or LoFIRRTL (see Chapter 11 of the spec) would be sufficient.

[seldridge]

@boqwxp: There does exist an Apache 2.0-licensed tree-sitter FIRRTL parser that may help here: https://github.com/chipsalliance/tree-sitter-firrtl.

Looping in @drom.

[drom]

Yes, @seldridge https://github.com/chipsalliance/tree-sitter-firrtl is a C++ parser and can be embedded in Yosys if someone is interested to do so.

[boqwxp]

@seldridge Oh, cool! Somehow I missed that in my search. Thanks for pointing that out, and @drom for giving your blessing.

I am currently working on some other stuff, but I am interested in taking this up in a few days once I finish with that.

[cliffordwolf]

What's wrong with just generating Verilog from FIRRTL and reading that into Yosys? When I originally discussed FIRRTL-Yosys integration with @azidar we thought that Verilog should work fine for that direction. cc @ucbjrl

[seldridge]

Having access to Yosys' equivalence checking at arbitrary points in the FIRRTL compiler would be useful to me. Some ideas:

• I'm a user writing a custom FIRRTL transform and I want to verify that my transform is not changing the function of the circuit. I can turn on a "safe execution mode" that runs Yosys equivalence checks on the FIRRTL IR before and after my transform.
• I'm a developer and I'm trying to track down bugs in FIRRTL's Verilog emitter. It would help if I could prove the equivalence of some FIRRTL IR and the emitted Verilog.

A fair amount of this would require supporting all of FIRRTL (as opposed to just low FIRRTL), but anything here would be helpful to me.

[whitequark]

What's wrong with just generating Verilog from FIRRTL and reading that into Yosys?

For example, the fact that RTLIL semantics is neither as stable nor as well-defined as FIRRTL semantics is.

In practical terms, I would like to switch nMigen to emitting LoFIRRTL rather than RTLIL, unless Yosys is planning to offer the same kind of backwards compatibility guarantees as FIRRTL does. (The resulting LoFIRRTL would, of course, still be consumed by Yosys.) But if I had to generate Verilog first it would defeat the purpose of the exercise.

[boqwxp]

Here is a relevant quote from IRC re: Verilog Considered Harmful.

<whitequark> I think the way 1364.1 defines a DFF with async set and reset is very enlightening
<whitequark> it *requires* you to write a code with sim/synth mismatch
<whitequark> *write a code pattern
<whitequark> meanwhile there's no well-defined "compilation target" subset at all with SystemVerilog, which is even worse than the poorly defined compilation target defined in 1364.1
<whitequark> which SV constructs do I have to implement to ingest the output of your HDL? well, the only way is to look at the sources of your tool
<whitequark> multiply by the number of tools.
<whitequark> there are tools that supposedly ingest Verilog that can't cope with concatenations on assign LHS

I think it is not only about why Verilog is bad for Yosys, but more about why Verilog is bad in general, and that Yosys should help encourage adoption of a better interchange format.

[boqwxp]

Unfortunately it looks like tree-sitter and thus https://github.com/chipsalliance/tree-sitter-firrtl depend on Node.js, which would add yet another dependency to Yosys. I'm not so enthusiastic about that, and I understand if it's a deal-breaker for Claire.

Maybe I'll take a stab at implementing a LoFIRRTL parser in flex+bison, cribbing the grammar from https://github.com/chipsalliance/tree-sitter-firrtl/blob/master/grammar.js .

[whitequark]

Maybe I'll take a stab at implementing a LoFIRRTL parser in flex+bison, cribbing the grammar from https://github.com/chipsalliance/tree-sitter-firrtl/blob/master/grammar.js .

That's what I would do if I was implementing it, so the approach sounds good to me.

[drom]

Unfortunately it looks like tree-sitter and thus https://github.com/chipsalliance/tree-sitter-firrtl depend on Node.js, which would add yet another dependency to Yosys. I'm not so enthusiastic about that, and I understand if it's a deal-breaker for Claire.

Maybe I'll take a stab at implementing a LoFIRRTL parser in flex+bison, cribbing the grammar from https://github.com/chipsalliance/tree-sitter-firrtl/blob/master/grammar.js .

@boqwxp tree-sitter and tree-sitter-firrtl is a C code generated from grammar.js It does not require you having Node.js https://tree-sitter.github.io/tree-sitter/using-parsers NPM published package have all C source generated.

[boqwxp]

@drom I see that, but I'm also not very enthusiastic about including only the output of some other tool and not the actual parser code itself. Maybe if it's a very robust, complete implementation of the FIRRTL spec with no chance of needing expansion or modification in the future that could be justified, but I am otherwise not in favor of that approach.

[drom]

@boqwxp I see. That is why YoSyS is just using a very light dependency chain! Coq, TeX, Python, Yacc, Bison, Flex, gawk, GraphViz, Tcl, Boost, ABC, xdot, etc.

[boqwxp]

Hey, I'm not the one who added those dependencies... Just because there's dependency bloat doesn't mean we should make the problem worse.

[whitequark]

@drom Yosys does not depend on Coq (you think it does because you blindly trust GitHub's faulty language autodetection feature), Bison is a replacement for Yacc, xdot and GraphViz are the same program that is only used for debugging, gawk is only used in tests, Tcl, Python and Boost are completely optional and can be omitted by most people. You should actually verify what you're saying so you don't end up claiming nonsense.

In practical terms, Yosys is one of the less demanding toolchains out there (and certainly not "bloated"), and dragging in Node.js as a dependency is something I would be entirely opposed to.

[boqwxp]

I have maybe 20% of an initial attempt at a skeleton for a FIRRTL frontend, nowhere even close to complete at https://github.com/boqwxp/yosys/tree/frontend-firrtl in case anyone wants to follow. I make no guarantees about development speed, though ;).

I actually did not even look at https://github.com/chipsalliance/tree-sitter-firrtl/blob/master/grammar.js ; I've just been reading the spec.

It's already clear to me that the significant indentation will be a pain (I really wish language designers would not do this...), and AFAICS from a very quick perusal the FIRRTL spec is silent on exactly what constitutes indentation. It might significantly simplify things to assume indentation consists exclusively of tabs. @seldridge do you know if that's a reasonable interpretation? Are there tools out there generating FIRRTL with spaces or, God forbid, some combination of spaces and tabs?

[seldridge]

tl;dr of my comments on firrtl#1562: The FIRRTL compiler implementation is spaces only. Tabs are disallowed/rejected (and therefore mixed tabs/spaces). This should be clarified in the spec. I'm checking with FIRRTL devs to just double check that this is what we want to enshrine.

[boqwxp]

OK, I see, thanks. I'm glad that mixing tabs and spaces is disallowed! :)

[whitequark]

@boqwxp Looking forward to using your frontend!