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.

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

Lowlevel LLVM-like language as HDL middle layer #19

Open
XVilka opened this Issue Nov 16, 2018 · 81 comments

Comments

Projects
None yet
@XVilka
Copy link

XVilka commented Nov 16, 2018

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

This comment has been minimized.

Copy link
Author

XVilka commented Nov 16, 2018

@kc8apf

This comment has been minimized.

Copy link

kc8apf commented Nov 16, 2018

@mithro

This comment has been minimized.

Copy link
Member

mithro commented Nov 16, 2018

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

This comment has been minimized.

Copy link

seldridge commented Nov 16, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

seldridge commented Nov 16, 2018

@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

This comment has been minimized.

Copy link

kc8apf commented Nov 16, 2018

@dvc94ch

This comment has been minimized.

Copy link

dvc94ch commented Nov 17, 2018

@Nic30

This comment has been minimized.

Copy link

Nic30 commented Nov 17, 2018

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

@Nic30

This comment has been minimized.

Copy link

Nic30 commented Nov 17, 2018

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

@dvc94ch

This comment has been minimized.

Copy link

dvc94ch commented Nov 17, 2018

@XVilka

This comment has been minimized.

Copy link
Author

XVilka commented Nov 17, 2018

@seldridge

This comment has been minimized.

Copy link

seldridge commented Nov 17, 2018

@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

This comment has been minimized.

Copy link

kc8apf commented Nov 17, 2018

@mithro

This comment has been minimized.

Copy link
Member

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.

@kc8apf

This comment has been minimized.

Copy link

kc8apf commented Nov 17, 2018

@XVilka

This comment has been minimized.

Copy link
Author

XVilka commented Nov 26, 2018

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
General discussion. Contribute to HardwareIR/meta development by creating an account on GitHub.
@XVilka

This comment has been minimized.

Copy link
Author

XVilka commented Nov 27, 2018

@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

This comment has been minimized.

Copy link
Author

XVilka commented Nov 27, 2018

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

@benreynwar

This comment has been minimized.

Copy link

benreynwar commented Nov 29, 2018

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

This comment has been minimized.

Copy link

seldridge commented Nov 29, 2018

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

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
Author: Steven Burns Affiliation: Intel Corporation Repository: https://github.com/intel/rapid-design-methods-for-developing-hardware-accelerators
@Nic30

This comment has been minimized.

Copy link

Nic30 commented Nov 30, 2018

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

This comment has been minimized.

Copy link

dvc94ch commented Nov 30, 2018

@dvc94ch

This comment has been minimized.

Copy link

dvc94ch commented Nov 30, 2018

@XVilka

This comment has been minimized.

Copy link
Author

XVilka commented Nov 30, 2018

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

@dvc94ch

This comment has been minimized.

Copy link

dvc94ch commented Nov 30, 2018

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

This comment has been minimized.

Copy link
Author

XVilka commented Nov 30, 2018

@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

This comment has been minimized.

Copy link

dvc94ch commented Nov 30, 2018

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

This comment has been minimized.

Copy link
Author

XVilka commented Nov 30, 2018

@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

This comment has been minimized.

Copy link

dvc94ch commented Nov 30, 2018

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

@Nic30

This comment has been minimized.

Copy link

Nic30 commented Nov 30, 2018

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

This comment has been minimized.

Copy link
Author

XVilka commented Feb 15, 2019

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

@seldridge

This comment has been minimized.

Copy link

seldridge commented Feb 16, 2019

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

This comment has been minimized.

Copy link

Nic30 commented Feb 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment