Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lowlevel LLVM-like language as HDL middle layer #19

Open
XVilka opened this issue Nov 16, 2018 · 105 comments
Open

Lowlevel LLVM-like language as HDL middle layer #19

XVilka opened this issue Nov 16, 2018 · 105 comments

Comments

@XVilka
Copy link

XVilka commented Nov 16, 2018 •
edited

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
Copy link
Author

XVilka commented Nov 16, 2018

Related f4pga/prjxray#58

This was referenced Nov 16, 2018
Closed
Closed
Open
Closed
Closed
@mx-shift
Copy link

mx-shift commented Nov 16, 2018 via email

This was referenced Nov 16, 2018
Open
Open
Closed
Closed
Open
Closed
Closed
Open
@mithro
Copy link
Contributor

mithro commented Nov 16, 2018 •
edited by unfurl-links bot

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.

@seldridge
Copy link

seldridge commented Nov 16, 2018 •
edited

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
Copy link

Nic30 commented Nov 16, 2018

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
Copy link

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

@mx-shift
Copy link

mx-shift commented Nov 16, 2018 via email

@XVilka XVilka mentioned this issue Nov 17, 2018
Open
@dvc94ch
Copy link

dvc94ch commented Nov 17, 2018 via email

@Nic30
Copy link

Nic30 commented Nov 17, 2018

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

@Nic30
Copy link

Nic30 commented Nov 17, 2018 •
edited

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

@dvc94ch
Copy link

dvc94ch commented Nov 17, 2018 via email

@XVilka
Copy link
Author

XVilka commented Nov 17, 2018 via email

@seldridge
Copy link

seldridge commented Nov 17, 2018 •
edited

@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

@mx-shift
Copy link

mx-shift commented Nov 17, 2018 via email

@mithro
Copy link
Contributor

mithro commented Nov 17, 2018

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.

@mx-shift
Copy link

mx-shift commented Nov 17, 2018 via email

@XVilka XVilka mentioned this issue Jun 14, 2019
Open
@eine
Copy link

eine commented Sep 18, 2019

Ref fabianschuiki/llhd

@drom
Copy link

drom commented Sep 19, 2019

I have started putting together tree-sitter-firrtl

@drom
Copy link

drom commented Sep 23, 2019 •
edited by unfurl-links bot

@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
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
Copy link

mx-shift commented Sep 23, 2019 via email

@Nic30
Copy link

Nic30 commented Oct 1, 2019

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.

@XVilka XVilka mentioned this issue Oct 17, 2019
Open
@eine eine mentioned this issue Jan 9, 2020
Closed
@eine eine mentioned this issue Mar 28, 2020
Closed
@eine eine mentioned this issue Apr 7, 2020
Closed
@nuess0r
Copy link

nuess0r commented Apr 23, 2020 •
edited by unfurl-links bot

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
Copy link
Author

XVilka commented Apr 23, 2020

@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
Copy link

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
Copy link

Nic30 commented Apr 23, 2020 •
edited

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
Copy link

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 XVilka mentioned this issue May 7, 2020
Open
@XVilka
Copy link
Author

XVilka commented Mar 12, 2021 •
edited by unfurl-links bot

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

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

@Nic30
Copy link

Nic30 commented Mar 12, 2021 •
edited by unfurl-links bot

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.

"for use with Xilinx Vitis HLS "

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

@Uroc327
Copy link

Uroc327 commented Mar 15, 2021

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

@umarcor
Copy link

umarcor commented Mar 17, 2021 •
edited

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
Copy link

Uroc327 commented Mar 17, 2021

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
Copy link

Nic30 commented Mar 17, 2021 •
edited

@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

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

@umarcor
Copy link

umarcor commented Mar 17, 2021 •
edited

@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
Copy link

umarcor commented Mar 17, 2021 •
edited

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
Copy link
Contributor

mithro commented Mar 17, 2021

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

@nuess0r
Copy link

nuess0r commented Mar 22, 2021 •
edited by unfurl-links bot

Impressive list of attempts and tools was gathered here. I agree that we should add everything that is not already in the awesome repo (This repo looks like a modern opencollector.org site :-) ).

I'll do that with this tool as well:
Some years ago I found out, that a massive toolset for designing asynchronous logic is open source. It's silicon proven (IBM TrueNorth, Achronix FPGAs) and is called HACKT - The Hierarchical Asynchronous Circuit Kompiler Toolkit
https://github.com/fangism/hackt

Original description: "HACKT is a project originally developed at Cornell University for aiding the design of asynchronous circuits. The project continues to be maintained by David Fang, the original author.
HACKT contains a collection of tools to aid asynchronous circuit design. (It is also usable for synchronous circuit design.)

Compiler -- the HAC input is compiled into object files, which are passed to other back-end tools
Simulators -- high-level and digital circuit simulators, and a VPI co-simulation module
Netlist Generator -- producing SPICE decks of circuits
Analysis -- the simulation environments also have strong support for analyzing concurrent behavior"

As it is targeted for asynchronous designs it is based on a completely different strain of languages. HAC source is CHP. Which is a improvement of CACM and CSP (both from C.A.R. Hoare).
So I have no idea if something inside this project is generic enough to be helpful for your discussion here, but I had to mention it for completeness.

In the paper "Alain J. Martin and Christopher D. Moore, CHP and CHPsim: A Language and Simulator for Fine-Grain Distributed Computation, 2011, Caltech Technical Report CS-TR-1-2011" I found once a rather short explanation of the development process.

GitHub
Hierarchical Asynchronous Circuit Kompiler Toolkit - fangism/hackt

@umarcor
Copy link

umarcor commented Mar 28, 2021 •
edited

I agree that we should add everything that is not already in the awesome repo

I added ~10 new items: https://github.com/hdl/awesome/commits/develop. Enhancements are welcome!

@XVilka
Copy link
Author

XVilka commented Jul 5, 2021

It's curious that the death rate among HLS solutions is the highest compared to the rest.

@XVilka
Copy link
Author

XVilka commented Aug 18, 2021

Chisel/FIRRTL is working on adding the support of RTLIL backend, it seems: chipsalliance/firrtl#2331

@Joejiong
Copy link

mark

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests