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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-441382660 and https://github.com/SymbiFlow/ideas/issues/19#issuecomment-441619546

[Nic30]

Also @rochus-keller you are kind of right. My question is how to provide universal API to HDL and persecute others to use it in the favour of theirs partially working solution. Using Yosys seems to be reasonable step.

[rochus-keller]

seems to you as academic flavour of the month?

Oh, you're right, FIRRTL is of course the flavour of the penultimate month - released sept. 18 ;-) RISC-V is a good thing and well adopted in industry, but I'm not aware that Chisel is really used somewhere outside academia; maybe you have references who give other evidence.

i can see that we are nearly in 2019, and we are still facing VHDL/Verilog as glorified industry standard.

Well, the same then applies to C, Unix, OO, ML and some other cool stuff.

[Nic30]

I can confirm that Cesnet, Codasip, RehiveTech are using HDL generators. Also every company which I know is not writing just pure VHDL/Verilog. When I look at your repositories @rochus-keller it seems to me that you see that HDL transpilers are widely used because Verilog is not enough. The problem is fragmentation of open hardware because everyone has own transpiler. This has to stop. Also every developer of HDL transpiler/compiler suffer from time issues, maybe if we work together it will greatly improve the product. But as you know thinking about doing is not same as doing...

[Dolu1990]

Well, the same then applies to C, Unix, OO, ML and some other cool stuff.

The difference is that C was designed as a programming language, while VHDL/Verilog wheren't designed as languages to describe RTL. Even when they are used to write testbench, they aren't that good.

Oh, you're right, FIRRTL is of course the flavour of the penultimate month - released sept. 18 ;-) RISC-V is a good thing and well adopted in industry, but I'm not aware that Chisel is really used somewhere outside academia; maybe you have references who give other evidence.

Maybe part of the issue is in Chisel, but in all cases the industry itself has a big issue, VHDL/Verilog are real bottlenecks, but it is quite hard to understand/fell those bottlenecks unless you deeply experiment a different ecosystem. Also, most hardware enginner don't have the training to understand the advanced capabilities of Chisel, and Chisel itself isn't advertising too much on advanced capabilities to not afraid people with software generators. Result of that is that many people think Chisel is just another Verilog but in scala, which is fondamentaly wrong.

[seldridge]

@rochus-keller: Chisel/FIRRTL users that I'm aware of, primarily as I sat through some talks just recently:

• SiFive (reference likely not needed)
• Intel [1], [2], [3]
• Google [4]
• IBM (I'm using it within IBM Research, but here's one usage [5])

Full product teams adopting it are relegated to SiFive and the Google Edge TPU product.

For some historical background: Chisel and FIRRTL grew out of DARPA's (ongoing) CRAFT program. Chisel has been around since 2012. FIRRTL grew out of a rewrite of Chisel 2 to add an IR, creating the Chisl front-end. FIRRTL has been a project since, as far as I'm aware ~2014 (but, possibly earlier).

Edit:

• Fixed an incorrect link to [3].

[dvc94ch]

Well, the same then applies to C, Unix, OO, ML and some other cool stuff.

I don't understand what you mean. I don't know why ML is an industry standard. Assuming you mean the language and not Machine Learning it's popular with compiler writers. Which I assume you think is a waste of time because we already have C, so why build a new compiler. I'm sure that if Ritchie had that mentality we might still be writting assembler or even better punching holes into a card.

[rochus-keller]

Thanks for the vivid discussions. I look forward reading the provided information. But it's getting off topic. You asked for opinions concerning "Lowlevel LLVM-like language as HDL middle layer". I put my arguments on record. I think we can agree that Chisel is no "HDL middle layer" candidate, regardless where it is used, and I would - from my current understanding - also FIRRTL rather see as an alternative offer to Verilog/SystemVerilog/VHDL, not as a "lowlevel HDL .. like LLVM Bitcode or WebAssembly"; on that level you rather find BLIF, EDIF or a primitive Verilog subset; but don't let me keep you from exploring new grounds ;-)

[Dolu1990]

@rochus-keller FIRRTL isn't an alternative to VHDL/Verilog/SystemVerilog. It was designed to represent a machine generated netlist. All the elaboration feature like functions, loop, parameters are gone from it. From memory, i remember that there is 3 level of feature defined in FIRRTL, probably @seldridge can expose them better than me, it would probably add some interresting axes of thinking.

[rochus-keller]

It was designed to represent a machine generated netlist.

To cite from Li, Izraelevitz, Bachrach (2018): Specification for the FIRRTL Language, Version 0.2, section 1.2 Design Philosophy, page 6: FIRRTL represents the standardized elaborated circuit that the Chisel HDL produces. FIRRTL represents the circuit immediately after Chisel’s elaboration but before any circuit simplification. It is designed to resemble the Chisel HDL after all meta-programming has executed. [..] For this reason, FIRRTL has first-class support for high-level constructs such as vector types, bundle types, conditional statements, partial connects, and modules. But I think we can leave this topic for now.

[Nic30]

Anyway, I think that we already failed on the start. Let's specify the 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?

[dvc94ch]

With electron-lang.org I thought that if I stick to a purely structural description, it is also possible to describe mixed signal circuits using the same ir. electron-lang is pretty much dead at the moment (mostly because nice stuff in my head often turns out into an imperfect reality) and didn't reach all of it's goals. With some contortions it generates yosys compatible json and uses yosys to convert it to verilog.

[XVilka]

@Nic30 I suggest both machine-readable bytecode to speed up processing of the complex topologies, and of course some readable text representation (assembly like, nothing more).

[Nic30]

About the needs of some projects I have seen (non authoritative response, fix me if I am wrong):

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 ?

[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: https://github.com/freechipsproject/chisel3/pull/1011#issuecomment-464243744.

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.

[eine]

Ref fabianschuiki/llhd

[drom]

I have started putting together tree-sitter-firrtl

[drom]

@drom and I have started building out parsers for BLIF ( https://github.com/gaffe-logic/tree-sitter-blif) ... @kc8apf What happened with the BLIF parser?

GitHub

Build software better, together

GitHub is where people build software. More than 40 million people use GitHub to discover, fork, and contribute to over 100 million projects.

[mx-shift]

I got distracted and haven't gotten back to it.

On Mon, Sep 23, 2019, 11:37 AM Aliaksei Chapyzhenka < notifications@github.com> wrote:

@drom https://github.com/drom and I have started building out parsers for BLIF ( https://github.com/gaffe-logic/tree-sitter-blif) ... @kc8apf https://github.com/kc8apf What happened with the BLIF parser?

https://camo.githubusercontent.com/cbfbdece72100f46536fc8c567f4fbdeb80df1c7/68747470733a2f2f6769746875622e6769746875626173736574732e636f6d2f696d616765732f6d6f64756c65732f6f70656e5f67726170682f6769746875622d6c6f676f2e706e67

https://camo.githubusercontent.com/4908d9947135e4536ef61d61512ee575f869bf6f/68747470733a2f2f6769746875622e6769746875626173736574732e636f6d2f66617669636f6e2e69636f GitHub Build software better, together https://github.com GitHub is where people build software. More than 40 million people use GitHub to discover, fork, and contribute to over 100 million projects.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SymbiFlow/ideas/issues/19?email_source=notifications&email_token=ACIEHF5ULL3KD3F2GYAPDPTQLEEFZA5CNFSM4GEZFBW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7L25KQ#issuecomment-534228650, or mute the thread https://github.com/notifications/unsubscribe-auth/ACIEHF3RZ5J3FDZIDQQLFGTQLEEFZANCNFSM4GEZFBWQ .

[Nic30]

After nearly a 0.75 year I do think that the HDL middle layer should have 4 separated components.

1. Format for description of digital circuits
2. Framework for conversion of 1 to 3
3. Universal HDL AST
4. Convertors from 3. to target HDL (SV/VHDL/FIRRTL...)

( The 1-3 difference is there because for analysis and optimisations something like graph database is required. 3 is something meant for hiding the differences between target languages and code-style specifications. If 1==3 the format would be inefficient or too complex. )

This components are already implemented in most of the mentioned tools. However they are somehow tightly coupled with the original tool itself or the format can not be practically used without some restricting frontend etc, so it is not possible to share code.

As I was not successful in convincing nearly any other project to keep this issue in mind. I am extracting things from our libraries so it is possible to swap it in future.

Today I just saw in MyHDL gitter that they are going to take the same way, probably.

[nuess0r]

Hi, I'm coming here due to a suggestion in the ghdl chat. The topic for a intermediate representation (IR) for HDLs is also worked on in academia. Early in April a paper which proposes a new IR was published: LLHD: A Multi-level Intermediate Representation for Hardware Description Languages https://arxiv.org/pdf/2004.03494.pdf

[XVilka]

@nuess0r thanks! This one is looking indeed quite promising. FIRRTL is good, but being written in Scala it makes embedding it somewhere close to impossible. @Nic30 was working on a more useful approach to implement such a standard in C++, but LLHD looks good from this point of view and quite complete to be usable right now (at least how it looks?).

[seldridge]

FIRRTL is good, but being written in Scala it makes embedding it somewhere close to impossible.

Small clarification: the extant implementation of the FIRRTL compiler is written in Scala, but the FIRRTL IR is just a specification and FIRRTL IR serializes to text. I do recognize that the former adds hurdles to people wanting to work with FIRRTL IR in languages which are not Scala (e.g., use of FIRRTL IR in a C++ project requires defining your own datastructures representing FIRRTL IR nodes).

[Nic30]

Seeing quite a lot of work done on LLHD/hdlConvertor/... makes me think that this issue was actually about avoiding of such a thing. At least @fabianschuiki was able to publish it.

@XVilka There was no community for netlistDB and that is why there is no development in progress. However I am finishing hdlConvertor which can parse SV2017, VHDL2008 in universal AST which can also be converted back and small subset can also be interpreted. I am using it to load design in to a tool similar to chisel3 (hwt) and in doc generator. (Note that universal HDL AST is somethig different than FIRRTL, netlist, behavioral/structural descr.)

@seldridge Is there something which compares a FIRRTL with a Verilog equivalent FIRRTL? I need some argument, why not to use just simplified Verilog and why to use another text format which requires an additional library etc. I know that this questions applies to any other format as well, but that makes me interested in response even more. I am planing to integrate FIRRTL in to hdlConvertor which will basically brings the FIRRTL to python/c++ word, but as there is no request for it it takes 1y+.

[seldridge]

Is there something which compares a FIRRTL with a Verilog equivalent FIRRTL?

Directly, no. However, you can compile FIRRTL IR to Verilog and then LEC that with some other Verilog.

This strategy is used in FIRRTL compiler regression tests to compare Verilog across compiler versions: (1) input FIRRTL is converted to Verilog using two versions of the compiler and (2) Yosys is used for equivalence checking.

[XVilka]

I think this is somewhat relevant since they use LLVM as the middle layer too: https://github.com/Xilinx/HLS

GitHub

Xilinx/HLS

Vitis HLS LLVM source code and examples. Contribute to Xilinx/HLS development by creating an account on GitHub.

[Nic30]

I think this is somewhat relevant since they use LLVM as the middle layer too: https://github.com/Xilinx/HLS

GitHubXilinx/HLSVitis HLS LLVM source code and examples. Contribute to Xilinx/HLS development by creating an account on GitHub.

"for use with Xilinx Vitis HLS "

GitHub

Xilinx/HLS

Vitis HLS LLVM source code and examples. Contribute to Xilinx/HLS development by creating an account on GitHub.

[Uroc327]

There is also llvm CIRCT, which aims at providing an llvm MLIR for hardware description.

[umarcor]

I gathered a list of 11 different projects which provide some kind of intermediate representation:

• RTLIL
• FIRRTL
• LLHD
• UHDM
• LGraph
• AHIR
• hdlAst
• calyx
• circt
• coreir
• spydrnet

All of them have some minimal overlap, but many are designed for an specific purpose or ecosystem. Is anyone aware of a discussion/review/comparison? Most of the papers/references I find are focused on describing features in isolation.

[Uroc327]

Is anyone aware of a discussion/review/comparison?

Not exactly a comparison, but circt uses FIRRTL and llhd as "dialects" to solve different problems. They have some documentation on what they ('d like to) use each dialect for.

[Nic30]

@umarcor I was considering writing the paper about this, but there are so many, the comparison of this is so subjective thing... and I do not want to write this kind of paper alone. I do maintain the list of similar things (note that categories are approximative):

ir centric:

• AHIR - C++, c -> VHDL
• calyx - rust/futil, Intermediate Language (IL) for Hardware Accelerator Generators
• circt - C++/LLVM, Circuit IR Compilers and Tools
• cirkit - C++, a logic synthesis and optimization framework
• chisel3.FIRRTL Hardware circuit description language for Chisel3
• fasm - Python, FPGA Assembly (FASM) Parser and Generator
• Yosys.RTLIL Verilog AST like IR in Yosys
• thorin The Higher-Order Intermediate Representation for LLVM
• lgraph.core Graph centric library for circuit developement
• mockturtle - logic network library
• percy - Collection of different synthesizers and exact synthesis methods for use in applications such as circuit resynthesis and design exploration.
• CoSA/coreir - CoreIR Symbolic Analyzer
• mockturtle - C++, a logic network library
• llhd - Rust, Low Level Hardware Description
• hdlConvertorAst - Python, universal AST for VHDL/Verilog
• hwt.hdl - Python, Lib for hardware generators with retrospectivity, type checking and HLS
• nmigen.hdl - Python, Toolbox for building complex digital hardware
• Torc - C++, Tools for Open Reconfigurable Computing
• UHDM - C++, Universal Hardware Data Model
• spydrnet - Python, framework for analyzing and transforming netlists
• netlistDB - C++, high performance netlist database

hls centric

• :skull: legup - 2011-2015, LLVM based c->verilog
• PandA-bambu - 2003-?, GCC based c->verilog
• :skull: augh - c->verilog, DSP support
• gemmini - scala, systolic array generator
• utwente-fmt - abstract hls, verification libraries
• :skull: Shang - 2012-2014, LLVM based, c->verilog
• :skull: xronos git2 - 2012-2016, java, simple HLS
• :skull: Potholes - 2012-2014 - polyhedral model preprocessor, Uses Vivado HLS, PET
• :skull: hls_recurse - 2015-2016 - conversion of recursive fn. for stackless architectures
• :skull: hg_lvl_syn - 2010, ILP, Force Directed scheduler
• abc <2008-?, A System for Sequential Synthesis and Verification
• :skull: polyphony - 2015-2017, simple python to hdl
• :skull: DelayGraph - 2016, C#, register assignment alghorithms
• PipelineC - 2018, Python, c -> hdl for a limited subset of c
• coreir - 2016-?, LLVM HW compiler
• spatial - , scala
• :skull: microcoder - ?-2019, Python, ASM like lang. -> verilog
• :skull: TAPAS - 2018-2019, c++, Generating Parallel Accelerators fromParallel Programs
• :skull: DHLS - 2019-?, C++, A Basic High Level Synthesis System Using LLVM
• :skull: ahaHLS - 2018-2019, A Basic High Level Synthesis System Using LLVM
• pluto - An automatic polyhedral parallelizer and locality optimizer
• :skull: ctoverilog ?-2015 - A C to verilog compiler, LLVM
• :skull: exprc - 2018-2018, C++, a toy HLS compiler
• :skull: kiwi 2003-2017
• :skull: ElasticC ?-2018 - C++, lightweight open HLS for FPGA rapid prototyping
• :skull: c-ll-verilog 2017-2017, C++, An LLVM based mini-C to Verilog High-level Synthesis tool
• xls - 2020-?, C++ HLS compiler with JIT

hcl centric

• autofpga - C++, A utility for Composing FPGA designs from Peripherals
• BinPy - Python, An electronic simulation library
• blarney - Haskell, HCL
• bsc - Haskell, C++, BSV - Bluespec Compiler
• chisel - 2012-?, Scala, HCL
• Chips-2.0 - , , FPGA Design Suite based on C to Verilog design flow
• circt - 2020-?, C++/LLVM, compiler infrastructure
• concat - 2016-?, Haskell, Haskell to hardware
• DUH - JS, simple convertor between verilog/scala/ipxact
• DFiant 2019-?, Scala, dataflow based HDL
• edalize - 2018-?, Python, abstraction layer for eda tools
• garnet -2018-?, Python, Coarse-Grained Reconfigurable Architecture generator based on magma
• hammer - 2017-?, Python, Highly Agile Masks Made Effortlessly from RTL
• heterocl - 2017-?, C++, A Multi-Paradigm Programming Infrastructure for Software-Defined Reconfigurable Computing
• hoodlum - 2016-?, Rust, HCL
• ILAng - modeling and verification platform for SoCs where Instruction-Level Abstraction (ILA) is used as the formal model for hardware components.
• :skull: jhdl - ?-2017, C++ Verilog/VHDL -> systemC, prototype
• Kactus2 - IP-core packager
• kratos - C++/Python, hardware generator/simulator
• lgraph - C, generic graph library
• llhd - Rust, HCL
• livehd - mainly C++, An infrastructure designed for Live Hardware Development.
• Lucid HDL in Alchitry-Labs - Custom language and IDE inspired by Verilog
• magma - 2017-?, Python, HCL
• migen - 2013-?, Python, HCL
• mockturtle - logic network library
• moore - Rust, HDL -> model compiler
• MyHDL - 2004-?, Python, Process based HDL
• nmigen -, Python, A refreshed Python toolbox for building complex digital hardware
• OpenTimer - , C++, A High-Performance Timing Analysis Tool for VLSI Systems
• percy - Collection of different synthesizers and exact synthesis methods for use in applications such as circuit resynthesis and design exploration.
• PyChip-py-hcl - , Python, Chisel3 like HCL
• pygears - , Python, function style HDL generator
• PyMTL3 2018-?
• PyMTL - 2014-?, Python, Process based HDL
• PipelineC - 2018-?, Python, C++ HLS-like automatic pipelining as a language construct/compiler
• PyRTL - 2015-?, Python, HCL
• Pyverilog - 2013-? Python-based Hardware Design Processing Toolkit for Verilog HDL
• rogue , C++/Python - Hardware Abstraction & Data Acquisition System
• sail 2018-?, (OCaml, Standard ML, Isabelle) - architecture definition language
• spatial - Scala, an Argon DSL like, high level abstraction
• SpinalHDL - 2015-?, Scala, HCL
• Silice - ?, C++, Custom HDL
• :skull: SyDpy - ?-2016, Python, HCL and verif. framework operating on TML/RTL level
• systemrdl-compiler - Python,c++, register description language compiler
• UHDM - C++ SystemVerilog -> C++ model
• :skull: Verilog.jl - 2017-2017, Julia, simple Julia to Verilog transpiler
• veriloggen - 2015-?, Python, Verilog centric HCL with HLS like features
• :skull: wyre - 2020-2020, Mupad, Minimalistic HDL

[umarcor]

@Uroc327 can you please provide some specific reference? I had a look at the meeting notes, but I found no descriptive explanation. I'm also aware of work in progress for UHDM to RTLIL and UHDM to Verilator. However, rather than one to one bridges, I'd like to know the technical motivations for creating some of those projects, provided that others existed already. For instance, my understanding is:

• The motivation for FIRRTL was (synthesizable) synchronous only and (initially) single-clock. That's why they didn't use Verilog or VHDL, which have a much larger scope.
• The motivation of Yosys was not to create an IL per se, so it's based directly on the synthesizable subset of Verilog. It got to be considered an "standard" representation because several frontends (Surelog, GHDL, Verific) target that API.
• UHDM was created for supporting System Verilog constructs, even though they are then simplified for targeting either RTLIL or Verilator.
• hdlAst was created as a result of building multiple ANTLR based parsers for HDLs.

From VHDL/GHDL's perspective, targeting UHDM seems like a sensible way forward, because it would potentially improve the synthesis and it would allow pre-synthesis mixed-language (VHDL + Verilog + System Verilog) simulation. It would also avoid having to write a ghdlator/vhdlator. Hence, I'd like to understand why target LLHD/CIRCT instead of UHDM, or whether UHDM is to be integrated into CIRCT, as LLHD seems to be.

[umarcor]

I was considering writing the paper about this, but there are so many, the comparison of this is so subjective thing... and I do not want to write this kind of paper alone.

@Nic30, I do agree with the wish and not willing to write it alone. In my case, I don't feel confident/authoritative enough for authoring a paper in this area. However, most of the content in a review paper would be descriptive about how long has each project been alive, who are the main developers, which are their motivations and how do they envision the future. Only the last section(s) need to contain some more subjective conclusions.

Unfortunately, I won't have time for doing a good writing in the following 3 months, at least. However, I would be interested in gathering the references and comments/descriptions. That is, having some place where I can add quotes and/or refs, when I find them.

I do maintain the list of similar things (note that categories are approximative):

The ir centric list is very similar to the one I posted. The hcl centric seems to be a superset of what I name "HDL project management tools" (umarcor.github.io/osvb/apis/core). I have almost no experience with HLS. Anyway, I agree that those three are the main challenges we have as a community, now that simulation and synthesis with open source tools is possible with a bunch of languages.

I assume that you did not write the list now, but you copied it from somewhere else. Would you mind pointing to the source (I guess, a repo of yours)? I would like to add the missing items to hdl.github.io/awesome? We can create a category named Tools > Intermediate Representation.

[mithro]

BTW I wouldn't put UHDM or FASM in the "general purpose ir" category like circt or chisel3.FIRRTL.

UHDM is designed to be a step above an AST to allow SystemVerilog parser frontends to be independent from the rest of the tool.

FASM is designed to be a human readable representation of the FPGA feature configuration. Kind of like how assembly is a human readable representation of the CPU's opcodes.

Neither is designed to allow "transformations" to be performed on the represented data (like optimization passes and such).