Lowlevel LLVM-like language as HDL middle layer

[XVilka]

Basic idea is to create something low-level, like LLVM Bitcode or WebAssembly, to create the HDL compilers emit the code in this format, which will be fed to the routers/synthesizers after. This will allow to add 1) targets easier 2) HDL frontends easier.

Criteria for selection:

• Do we expect it to have a human readable form? [BOTH]
  • binary version
    - a text version with extracted symbol table?
    - more tops per file?
    - Include?
• behavioural description / pure structural? [STRUCTURAL]
  - process (Verilog like mux, reg... desc.) / netlist (mux, reg, ... descr. by instance) ?
  - is Chisel3 FIRRTL/Yosys RTLIL structural enough?
• Do we want it to be technology independent? [YES]
• Do we require parameters/preprocessor? [NO]
• Granularity gate / operator / process?
• Which has the priority in optimizations: loading time/analysis/modification/file size?
• Support for tristate signals?
  - Support for strong/weak pull up/down?
• Clock domain as a wrapper around part of the netlist/ only as a input clk to registers?
• Support for synthesis related pragmas like multiclock path, clock domain crossing?

Needs of the particular projects:

Chisel3

• netlist of statements (process without explicit sensitivity)?

HWT

• netlist of statements

magma

• netlist of statements

MyHDL

• processes

SpinalHDL

• netlist of statements

Veriloggen

• whole Verilog

Yosys

• netlist of hw processes ?

Updates from #19 (comment) and #19 (comment)

[XVilka]

Related SymbiFlow/prjxray#58

[kc8apf]

That's the medium-term goal for Gaffe after enough basic libraries exist to do things like parse BLIF and serialize a graph. See also https://github.com/rdaly525/coreir.

…

On Fri, Nov 16, 2018 at 5:51 AM Anton Kochkov ***@***.***> wrote: Related SymbiFlow/prjxray#58 <SymbiFlow/prjxray#58> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJBDl336Ug4ALYUIzXMA9714Klb3eaqcks5uvsLSgaJpZM4YmSht> .

[mithro]

There is also https://bar.eecs.berkeley.edu/projects/firrtl.html

FIRRTL (A Flexible Intermediate Representation for RTL) is motivated by the success of Chisel and has two parts: 1) a specification of the formalized elaborated graph that the Chisel DSL produces, prior to any simplification, and 2) a library of micro-passes that are used to simplify, transform, or specialize arbitrary FIRRTL graphs.

UCB-BAR: FIRRTL

[seldridge]

Edit: @mithro beat me by a few minutes! Original reply with more detail on FIRRTL below.

Are you aware of FIRRTL?

Chisel3 already compiles to FIRRTL (a flexible intermediate representation of RTL analogous to "LLVM IR for circuits"). There exists a Verilog to FIRRTL path through Yosys and some other frontends are compatible (Magma can target FIRRTL, an experimental version of HALIDE can target FIRRTL, and Spatial targets Chisel). The FIRRTL compiler is an optimizing compiler with a provided backend for Verilog. Any FPGA/ASIC tool vendor, if they so desire, can directly use FIRRTL for synthesis and place and route if they want to support it. Any user wanting to build a new frontend can target FIRRTL. Any user wanting to write a new backend (e.g., for VHDL) can consume FIRRTL. Additionally, FIRRTL uses an "annotation" concept for attaching metadata to specific components in a circuit. This quickly becomes necessary for controlling downstream FIRRTL transforms and for use by downstream ASIC/FPGA tools, e.g., pad placement, clock timing information, etc. Automatic operation of downstream tools using annotations is being developed in the HAMMER project.

FIRRTL, through it's Verilog generation path, is battle tested, having been used to generate Verilog used for numerous tape outs at Berkeley and SiFive (Rocket Chip and BOOM RISC-V microprocessors) Google (Edge TPU), and other institutions/companies. It seems reasonable to cut out the Verilog/VHDL middle man in all this. That will require buy-in from closed source CAD vendors.

(Note: this is an expanded copy/paste of a reply in the associated issue filed issue on the Chisel3 repo.)

[Nic30]

There is also coreir.

The open hardware community really needs such a language, It is quite clear. I think that FIRRTL is good enough and already has large community. It would be great to have FIRRTL library for some languages like C++/Python/Java managed by creators of FIRRTL. If such a library exists for Python3 It would save me a lot of time and it will ensure the better compatibility in future.

I have some "hdl transpiler" HWT (meta-HDL + verification env.) as you found and I will probably use FIRRTL as in backend in next release.
I plan to break int small libraries and donate it to other projects like magma or SpinalHDL.

There are many hardware generators, for example P4-to-VHDL. Problem is that the autors of such a tools have to implemented lots of same code over and over. The project are completely incompatible. It is not just FPGA-like assembly language and to VHDL/Verilog/SystemC conversions. There are graph algorithms which literary everyone has to implemented, like searching of isomorphic graphs etc.

@XVilka I think that there is a great opportunity in abstract specification of interface functions rather than in next FPGA-like assembly language. I have experimented with automatically generated DMA engines. The results are promising. The goal is to allow transaction level description with some extra meta-information specified by user. Not entirely the HLS bus some kind of metalanguage and automatic pipeline generator.

I think the first step is to create some consortium-like group for driving of the development of FIRRTL libraries in different programming languages and for management of libraries which are using FIRRTL. There is a very long road ahead (verifications, simulator-driver interfaces, analysis, HLS, architecture retargeting...), we need to act fast.

What ever you end up doing I am ready to help.

[seldridge]

@Nic30: good points.

• Python/C/C++/MyLanguage libraries for FIRRTL seems to make sense to improve the ease of frontend/backend development. The existing antlr and protobuf specifications for FIRRTL may already ease this.
• Yes, the idea is to not have everyone write the same dead code elimination/constant propagation passes...

On the Chisel/FIRRTL side, we're trying to come up with some clear governance around Chisel/FIRRTL. We have Reviewer Guidelines upstreamed and a Constitution and Contributions PR'd. This is taking place on the chisel-lang-governance repo and all of this is open to issues/PRs. The intent is to eventually have a catching organization/consortium for these projects. This is in its nascent form as the Free Chips Project GitHub Organization. However, this primarily exists on GitHub at this time...

We just wrapped up the first Chisel Community Conference in the Bay Area and are planning to send out a form to identify what areas of development or non-development (testing upstream on big internal projects, outreach, etc.) individuals would be willing to help out on. This is expected to be posted on the chisel-users and chisel-announce mailing lists, but we can publicize this more widely (i.e., here).

[kc8apf]

@drom and I have started building out parsers for BLIF ( https://github.com/gaffe-logic/tree-sitter-blif) and Verilog ( https://github.com/drom/tree-sitter-verilog) based on http://github.com/tree-sitter/tree-sitter. So far, tree-sitter feels easier to develop a grammar and tests in. The result is a pure-C, incremental parser that already has bindings to Rust, Haskell, JavaScript, and Ruby. Higher-level libraries that convert the resulting ASTs into a language-specific, semantic representation will still need to be built after the parsers are ready. If someone wrote a tree-sitter parser for FIRRTL, we'd be well on our way toward having a reusable library that works both for toolchain components as well as editors and language servers. As for having a single organization, currently there are many: Free Chips Project, SymbiFlow, YosysHQ, Gaffe Logic, FOSSi. Most of these are loose affiliations related to a single tool or family of tools. I'm unclear on any benefit to having a single governing body for these widely-varied projects. Certainly having a focused place for community discussions would be helpful. Some of the larger projects might benefit from clearer governance. If someone wants to talk about different governance models, licensing, and foundations, please get in touch. I spent ~1yr working with Linux Foundation to get OpenBMC setup as an independent project with contributors from IBM, Intel, Facebook, Google, and Microsoft. I can definitely assist in getting everyone in touch with the major players in the free and open software foundations. Rick

…

On Fri, Nov 16, 2018 at 1:11 PM Schuyler Eldridge ***@***.***> wrote: @Nic30 <https://github.com/Nic30>: good points. - Python/C/C++/MyLanguage libraries for FIRRTL seems to make sense to improve the ease of frontend/backend development. The existing antlr and protobuf specifications for FIRRTL may already ease this. - Yes, the idea is to not have everyone write the same dead code elimination/constant propagation passes... On the Chisel/FIRRTL side, we're trying to come up with some clear governance around Chisel/FIRRTL. We have Reviewer Guidelines upstreamed and a Constitution and Contributions PR'd. This is taking place on the chisel-lang-governance <https://github.com/freechipsproject/chisel-lang-governance> repo and all of this is open to issues/PRs. The intent is to eventually have a catching organization/consortium for these projects. This is in its nascent form as the Free Chips Project GitHub Organization <https://github.com/freechipsproject/>. However, this primarily exists on GitHub at this time... We just wrapped up the first Chisel Community Conference in the Bay Area and are planning to send out a form to identify what areas of development or non-development (testing upstream on big internal projects, outreach, etc.) individuals would be willing to help out on. This is expected to be posted on the chisel-users <https://groups.google.com/forum/#!forum/chisel-users> and chisel-announce <https://groups.google.com/forum/#!forum/chisel-announce> mailing lists, but we can publicize this more widely (i.e., here). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJBDl2ayq9ZMn6O5aXg09UEMsK5yVdNCks5uvyn7gaJpZM4YmSht> .

[dvc94ch]

Hmm it's been a while since I looked at the firrtl spec, but I seem to recall that there is one implicit clock thereby not supporting multiple clock domains and not making it very useful for FPGAs.

…

On Fri, Nov 16, 2018, 22:25 Rick Altherr ***@***.*** wrote: @drom and I have started building out parsers for BLIF ( https://github.com/gaffe-logic/tree-sitter-blif) and Verilog ( https://github.com/drom/tree-sitter-verilog) based on http://github.com/tree-sitter/tree-sitter. So far, tree-sitter feels easier to develop a grammar and tests in. The result is a pure-C, incremental parser that already has bindings to Rust, Haskell, JavaScript, and Ruby. Higher-level libraries that convert the resulting ASTs into a language-specific, semantic representation will still need to be built after the parsers are ready. If someone wrote a tree-sitter parser for FIRRTL, we'd be well on our way toward having a reusable library that works both for toolchain components as well as editors and language servers. As for having a single organization, currently there are many: Free Chips Project, SymbiFlow, YosysHQ, Gaffe Logic, FOSSi. Most of these are loose affiliations related to a single tool or family of tools. I'm unclear on any benefit to having a single governing body for these widely-varied projects. Certainly having a focused place for community discussions would be helpful. Some of the larger projects might benefit from clearer governance. If someone wants to talk about different governance models, licensing, and foundations, please get in touch. I spent ~1yr working with Linux Foundation to get OpenBMC setup as an independent project with contributors from IBM, Intel, Facebook, Google, and Microsoft. I can definitely assist in getting everyone in touch with the major players in the free and open software foundations. Rick On Fri, Nov 16, 2018 at 1:11 PM Schuyler Eldridge < ***@***.***> wrote: > @Nic30 <https://github.com/Nic30>: good points. > > - Python/C/C++/MyLanguage libraries for FIRRTL seems to make sense to > improve the ease of frontend/backend development. The existing antlr and > protobuf specifications for FIRRTL may already ease this. > - Yes, the idea is to not have everyone write the same dead code > elimination/constant propagation passes... > > On the Chisel/FIRRTL side, we're trying to come up with some clear > governance around Chisel/FIRRTL. We have Reviewer Guidelines upstreamed and > a Constitution and Contributions PR'd. This is taking place on the > chisel-lang-governance > <https://github.com/freechipsproject/chisel-lang-governance> repo and all > of this is open to issues/PRs. The intent is to eventually have a catching > organization/consortium for these projects. This is in its nascent form as > the Free Chips Project GitHub Organization > <https://github.com/freechipsproject/>. However, this primarily exists on > GitHub at this time... > > We just wrapped up the first Chisel Community Conference in the Bay Area > and are planning to send out a form to identify what areas of development > or non-development (testing upstream on big internal projects, outreach, > etc.) individuals would be willing to help out on. This is expected to be > posted on the chisel-users > <https://groups.google.com/forum/#!forum/chisel-users> and chisel-announce > <https://groups.google.com/forum/#!forum/chisel-announce> mailing lists, > but we can publicize this more widely (i.e., here). > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#19 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AJBDl2ayq9ZMn6O5aXg09UEMsK5yVdNCks5uvyn7gaJpZM4YmSht > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAtRr3COwcw89RAajS5Fle4if1QvocjXks5uvy1bgaJpZM4YmSht> .

[Nic30]

@kc8apf why are you not using ANTRL4 C++ runtime?

[Nic30]

@dvc94ch Is it possible to have more than single clock domain in current FIRRTL?

[dvc94ch]

Also if someone is writing a hdl in xyz, they may not like introducing a dependency on the jvm. It should be able to link statically or dynamically to a compiler toolkit imo, but maybe that's just me...

…

On Sat, Nov 17, 2018, 11:55 Nic30 ***@***.*** wrote: @dvc94ch <https://github.com/dvc94ch> Is there really possible to have only one clock domain ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAtRr7-7B-B8XkOdOogx7pBK2iR6bm6wks5uv-sEgaJpZM4YmSht> .

[XVilka]

Agree, ideal implementation should be in C/C++, so every other language/framework can link them very easily.

…

On Sat, Nov 17, 2018, 7:15 PM David Craven ***@***.*** wrote: Also if someone is writing a hdl in xyz, they may not like introducing a dependency on the jvm. It should be able to link statically or dynamically to a compiler toolkit imo, but maybe that's just me... On Sat, Nov 17, 2018, 11:55 Nic30 ***@***.*** wrote: > @dvc94ch <https://github.com/dvc94ch> Is there really possible to have > only one clock domain ? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#19 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AAtRr7-7B-B8XkOdOogx7pBK2iR6bm6wks5uv-sEgaJpZM4YmSht > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMZ_XYG-j2aiKyqWwkuI45YZKodWZZXks5uv-_PgaJpZM4YmSht> .

[seldridge]

@dvc94ch, @Nic30: FIRRTL supports arbitrary numbers of clocks and, consequently, you can use FIRRTL IR to write circuits with multiple clock domains.

You may have been thinking of the default behavior of Chisel modules where one implicit clock and one implicit reset is included. However, there's now a type hierarchy of modules, allowing you to easily remove the implicit clock and reset if you want/need more control. If you want more clocks, you add them as IO and can use scoping to control how they get used. The wiki page for Chisel3 goes into some examples that may help explain what that API looks like: https://github.com/freechipsproject/chisel3/wiki/Multiple-Clock-Domains

[kc8apf]

One of my goals is to use the same parsers for editor features such as syntax highlighting, identifier renaming, etc. Those require as-you-type performance and incremental parsing, precisely what tree-sitter was designed for. I'm also planning to write most of my tools in Rust which is not available as an ANTLR target. I could use the C++ target and then wrap the API but tree-sitter already offers Rust bindings. Now that I've been using tree-sitter, I really appreciate how simple writing test cases for the parser is. I see that as a big strength for improving the quality of the parser over time as learning how to write a new test is trivial. Rick

…

On Sat, Nov 17, 2018, 2:53 AM Nic30 ***@***.*** wrote: @kc8apf <https://github.com/kc8apf> why are you not using ANTRL4 C++ runtime? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJBDl-uoXP_91rqt2s91RUHYftTFJBTZks5uv-qtgaJpZM4YmSht> .

[mithro]

Maybe we should split the topic of parsers and low level IR? While they are somewhat related I think there are definitely different goals here.

[kc8apf]

Sure. Parsers are a somewhat later concern. Any IR will need a detailed spec to enable a variety of implementations. An existing grammar (ANTLR or otherwise) is insufficient as a spec though I expect an IR to have a very solid parser and generator for widespread adoption to occur.

…

On Sat, Nov 17, 2018, 11:24 AM Tim Ansell ***@***.*** wrote: Maybe we should split the topic of parsers and low level IR? While they are somewhat related I think there are definitely different goals here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJBDl9IDci787HuT91HgCDjnYuQ9X156ks5uwGJhgaJpZM4YmSht> .

[XVilka]

I created an organization and invited you as an owners @Nic30 @seldridge , so you can do whatever you like with access/whatever. I also created https://github.com/HardwareIR/meta for this discussion, so probably some summary can formed. You can also rename organization too

GitHub

HardwareIR/meta

General discussion. Contribute to HardwareIR/meta development by creating an account on GitHub.

[XVilka]

@Nic30 updated the top post with information from your comments, so it will be visible from the start. Too bad it is impossible to allow just edit it.

[XVilka]

Was also pointed to http://rsim.cs.illinois.edu/Pubs/17-PPOPP-HPVM.pdf - worth checking out.

[benreynwar]

I'm in favour of going with either:

1. FIRTTL simply because there's already a bunch of work done, and it doesn't seem like there are any issues that can't be fixed with a bit of work.
2. A very restricted subset of verilog.

I think a common IR will also be useful in taking timing reports, error messages and other tool outputs and transforming them up to the level of the HDL. At the moment it's difficult to do the timing analysis and the verification without going down to the verilog level. This negates a lot of the benefits of the HDL since the generated verilog is more difficult to deal with.

Design
HDL -> IR -> verilog

Timing Reports, Error messages ....
verilog -> IR -> HDL

[seldridge]

@benreynwar: It's hidden in a link above, but Intel has had some success doing IR-level analysis for area and timing:

• intel/rapid-design-methods-for-developing-hardware-accelerators
• https://www.youtube.com/watch?v=FktjrjRVBoY (recent presentation video)

This isn't intended as a replacement for tape-in analysis. However, it's apparently proved useful for finding bad design decisions early, e.g., big combinational logic chains. I'm not sure how far you can push this idea before having to do synthesis/place-and-route, but it would seem that doing IR-level analysis would let designers iterate faster, produce better designs, and reduce a reliance on proprietary tools early in the design process.

YouTube

FIRRTL Pass for Area and Timing

Author: Steven Burns Affiliation: Intel Corporation Repository: https://github.com/intel/rapid-design-methods-for-developing-hardware-accelerators

[Nic30]

I will collect results of our discussion in to some document after 12.8, (currently I am out of time).
So do not be shy to share any interesting projects or facts.

Also description of unique properties which makes some small project better than everything else is welcomed.
Also I do not know if there is some DSP library for chisel3 which actually works and does not requires to manually instantiate DSP blocks (like DSP48E1).

[dvc94ch]

My non-expert opinion is the following: There are two large application areas for FPGAs. 1. Specialized SoCs for embedded systems 2. Application specific hardware accelerators for offloading For 1. a source language like chisel is appropriate. For 2. maybe something like a standard library written in chisel and a source language that translates to spirv (glsl) might be more appropriate. Then there is the issue of tooling and what abstraction level that is most suitable for a specific task. I think that one ir won't fit all problems. I could imagine a set of three ir's to work out. 1. Something close to spirv (subset/superset) 2. Something close to firrtl (superset) 3. A structural netlist ir similar to yosys json format (superset that also has non digital circuits in mind)

[dvc94ch]

FYI I have used antlr before and porting it to a new language is a non trivial task that involves rewriting the runtime. After the discussion here about tree-sitter, I gave it a try for parsing a small dsl for specifying keybindings: ``` mode "command" { bind i -> mode("insert") bind p -> action("paste") bind SPC 2 -> action("focus-2") } ``` And it's pretty neat. It's also very easy to add support for new languages, since it has a very small C API surface.

[XVilka]

@dvc94ch you can choose to make a library without exposing ANTLR parser internals though

[dvc94ch]

I guess you could port the runtime to dependency free c and then provide bindings to other languages. But I don't see why anyone would want to do that. As I said it's a non trivial task. Look for example at the typescript port that multiple people familiar with antlr internals worked on. It's unusable...

[XVilka]

@dvc94ch But why you would need to rewrite the runtime? For example, if you want to use the ANTLR4 generated library in C++ in Java/Scala code - just use JNI or JNA, or any other bindings for your language.

[dvc94ch]

I'm not really familliar with jni or jna. But it's defenitely not dependency free if it requires a jvm to be present, likely even a specific version of the jvm. Trying to create binaries for multiple platforms is a boring and hard task in itself for any non trivial program. Having to bundle and distribute a jvm hardly makes this easier. I guess everyone has their preferences, so I guess we won't reach an agreement.

When working with @kasbah on electro grammar, we decided at the time to use antlr and reimplement the library part in every language. We quickly ran into the problem of the different language ports being out of sync (js and python) and started writing a language agnostic parser test suite (which tree sitter already has). Even before going this route I though writing electro grammar in rust and writing bindings for multiple languages was a better idea, but it being @kasbah's project I let myself be convinced to do it with antlr. Version 2 of electro-grammar never made it.

[XVilka]

@dvc94ch why do you need JVM for non Java? Idea is to create C++ library which you can use from whatever language you want. If you use it from Java/Scala/whatever - use JVM plus JNI/JNA. If you use Haskell or OCaml - just use bindings, Python, Ruby, whatever - same.

[dvc94ch]

I see, sorry I misunderstood you. Haven't used the c++ antlr backend.

[Nic30]

Yes, there is a ANTLR4 C++ (and for other lang. as well) run-time.
After you generate your parser (C++ files) you are not dependent on java etc. 1y ago ANTLR4 C++ run-time was quite buggy and fixing it was quite challenging but now it should be fully operational and stable.

[XVilka]

Note that asynchronous reset had been merged in FIRRTL master, thus removing one of the complain points.

[seldridge]

Related to the new Asynchronous Reset type in FIRRTL, there's a question that has come up for which some of your input would be good:

Should Asynchronous Resets be inferred in FIRRTL by what is connected to? Or: should the type of the reset in the FIRRTL IR be entirely statically determined?

This comes up (for us) as we'd like to be able to describe modules in Chisel that are agnostic to the type of reset. If you connect to this with an asynchronous reset, you'd like to get an asynchronous reset in your Verilog. If you connect to this with a synchronous reset, you'd like to get a synchronous reset in the emitted Verilog.

Alternatively, the FIRRTL IR can mandate that the reset type must be fully defined.

We're leaning towards the former idea of doing "reset inference" based on connection. It's not hard to do, but it's the first instance of something being abstract in FIRRTL. Everything else is static in the IR, with the exception of widths that may be inferred.

This further matters for others trying to target the FIRRTL IR as it places a restriction on whether or not the reset type has to be defined. Has this come up for anyone working on other hardware IRs or in writing "higher than Verilog/VHDL" languages?

There's some more info in the related Chisel PR here: freechipsproject/chisel3#1011 (comment).

Comments welcome.

[Nic30]

Idea:

• The registers can have multiple types of reset/reset value.

• The reset type can be part of the clock domain definition or the definition of the register.

• => The reset type for register can not be interfered from the high level code without explicit specification.

• Each register can have property which specifies the sync and async reset expression.

This suits well for the use-case where the async reset is used in special component/IO like async FIFO.

However if the use case is to use different type of reset in the design. It may be better to just use transformation of circuit to rewrite reset types.

I do have 2 implementation of IR, in 2. I am focusing on performance, parallel processing and graph database like API. But they probably would not be useful to you yet.