ideas
ideas copied to clipboard
f4pga
Lowlevel LLVM-like language as HDL middle layer
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:
- netlist of statements (process without explicit sensitivity)?
- netlist of statements
- netlist of statements
- processes
- netlist of statements
- whole Verilog
- 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
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 [email protected] wrote:
Related SymbiFlow/prjxray#58 https://github.com/SymbiFlow/prjxray/issues/58
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439398716, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBDl336Ug4ALYUIzXMA9714Klb3eaqcks5uvsLSgaJpZM4YmSht .
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.
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.)
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.
@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).
@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 [email protected] 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439528506, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBDl2ayq9ZMn6O5aXg09UEMsK5yVdNCks5uvyn7gaJpZM4YmSht .
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 <[email protected] 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 < [email protected]> 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439528506, 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439533093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtRr3COwcw89RAajS5Fle4if1QvocjXks5uvy1bgaJpZM4YmSht .
@dvc94ch Is it possible to have more than single clock domain in current FIRRTL?
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 <[email protected] 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439607909, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtRr7-7B-B8XkOdOogx7pBK2iR6bm6wks5uv-sEgaJpZM4YmSht .
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 <[email protected] 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 <[email protected] 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439607909, 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439609005, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMZ_XYG-j2aiKyqWwkuI45YZKodWZZXks5uv-_PgaJpZM4YmSht .
@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
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 <[email protected] 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439607837, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBDl-uoXP_91rqt2s91RUHYftTFJBTZks5uv-qtgaJpZM4YmSht .
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.
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 <[email protected] 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 https://github.com/SymbiFlow/ideas/issues/19#issuecomment-439641220, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBDl9IDci787HuT91HgCDjnYuQ9X156ks5uwGJhgaJpZM4YmSht .
@seldridge I'll have to try chisel, firrtl again sometime. Spinalhdl has added preliminary support for formal assertions etc. That would also be awesome to have support for in an ir.
@seldridge After I finish UVM like API for Verilator (+- 1 month) I can help with C++/Python FIRRTL. I have experience with ANTRL4, hardware design, etc. It would be great if anyone else can join as well.
Also there is a https://github.com/drom/awesome-hdl. It would be great if anyone could just read about available tools on some well known place. I think that now your are more or less lucky if you found some tool. Also more options can better predict behavior of userbase in opensource projects.
GitHub
Hardware Description Languages. Contribute to drom/awesome-hdl development by creating an account on GitHub.
It might worth to create a GitHub organization for this, so all different projects's maintainers will have an access to developing the common library/libraries.
@XVilka Maybe GitHub organization can help. But my experience says it don't because it does not brings a clear profit to others. Anyway I would try it.
I have a plan (C++/Python FIRRTL), it would be great if I magma @leonardt migen @sbourdeauducq and others would be able to use it. I mean I hate doing opensource opened just for two companies. I can accept your change requests and make the FIRRTL library just like you need.
(In 1st phase only profit from using FIRRTL is unified conversion to HDL and inter-project compatibility, but most importantly it will allow to develop optimizers which will solve hard graph problems without the care about input language or used HDL framework.)
FYI: I am working on an open source VHDL parser/language server written in Rust (https://github.com/kraigher/rust_hdl/). So If you need to parse VHDL code you are welcome to use/contribute to my project.
Contribute to kraigher/rust_hdl development by creating an account on GitHub.
Who is familiar with FIRRTL? @christiaanb asking "It's very unclear whether FIRRTL has asynchronous resets, so I don't know whether it can be a target."
As @XVilka mentions: I'm very interested as to whether the registers generated by FIRRTL have synchronous or asynchronous resets. Clash has support for both reset strategies; given that in FPGA land, on Intel/Altera fabric, registers have native asynchronous resets, while on Xilinx fabric, registers have native synchronous reset ports.
Browsing through the FIRRTL source, the only reference to always blocks was the following one:
https://github.com/freechipsproject/firrtl/blob/4a2211c1602b37a65b4e44c3b7ebe82e8bfeedc0/src/main/scala/firrtl/Emitter.scala#L791-L795
which seems to suggest that FIRRTL currently generates registers with a synchronous reset port.
And the spec doesn't mention at all as to whether the registers have synchronous or asynchronous reset ports; nor whether the semantics would allow for both reset strategies.
Apart from missing asynchronous resets there are also these issues in FIRRTL (by @Dolu1990 in https://github.com/SpinalHDL/SpinalHDL/issues/158#issuecomment-440996391 ):
- Quite weak clock domain support (no falling edge, no active low reset, no FPGA bistream reset)
- As far i know there is now support for Signal/components attributs (Quite often use by synthesis tools to give directives as KEEP, RAM_STYLE, ...)
- Inability to assign some bits of a combinatorial signal. For example
myWire(4 downto 2) := miaou - Driven by the Chisel needs (for the moment, which is a subset of what everybody need)
In short, this is a common issue with Chisel/FIRRTL : freechipsproject/firrtl#219 => low priority
it realy annoys me.
Blackbox Escape Hatch
The robust blackbox support in Chisel and backed by FIRRTL ExtModule acts as an escape hatch for almost everything stemming from, "I can do this in Verilog, but not Chisel/FIRRTL." This handles a lot of either the weird exceptional cases or known feature requests like asynchonous resets that we're intending to support.
Asynchronous Resets
Yes, Chisel and FIRRTL do not natively support asynchronous resets. There's tracking issues about this on the Chisel repository here:
- https://github.com/freechipsproject/chisel3/issues/343
- https://github.com/freechipsproject/firrtl/issues/219
These aren't terrifically hard to do, but it just hasn't gotten done because there's a good-enough workaround that Rocket Chip has used extensively via BlackBoxes. Their specific implementation is linked below:
Currently FIRRTL treats Chisel-land resets as one-width UInts, so they're always synchronous. There's an ongoing discussion on what to do with the FIRRTL IR type hierarchy to best support this. (Does Reset subclass Clock? Is it something else?)
The criticism of "you can't use Chisel/FIRRTL in an ASIC chip" is mostly overblown with experimental evidence. SiFive, Berkeley, Google, (others who haven't announced publicly), have taped out a lot of chips and haven't seen this as a showstopper. There's been some inertia with asynchronous resets, though, as once some users have a good solution that works there's less pressure on the developers to implement the better solution. In short: it's an issue, we're working on it... if that timeframe doesn't work and you have ideas on how to improve things and want to help, we'd love to get you involved, though! (:wave: @Dolu1990)
SpinalHDL Criticisms
Spinal is (and correct me if I'm wrong @Dolu1990) a rewrite of Chisel2 implementing a lot of feature requests and fixing a lot of the issues that @Dolu1990 hit with Chisel2. If we can get some of these ideas into Chisel3, we'd be happy to do it. However, there's a limited number of developers...
Responding inline to these:
- Quite weak clock domain support (no falling edge, no active low reset, no FPGA bistream reset)
There's robust support for multiple clock domains (chisel3/wiki/Multiple-Clock-Domains). @azidar has just PR'd clock domain analysis support.
There's been a discussion on how to support neg-edge triggered things in:
- https://github.com/freechipsproject/firrtl/issues/695
This is on the agenda, but there hasn't been substantial need (i.e., developer pressure) outside of things which are going to be Blackboxed anyway (e.g., JTAG). It's also not clear how to best expose this to users via a good API so that they don't go nuts with it like they do in Verilog.
As far i know there is now support for Signal/components attributs (Quite often use by synthesis tools to give directives as KEEP, RAM_STYLE, ...)
There have been discussions about this. Basically, you'd like to be able to add custom emission to the Verilog emitter. There's an active issue here:
- https://github.com/freechipsproject/firrtl/issues/941
Inability to assign some bits of a combinatorial signal. For example myWire(4 downto 2) := miaou
Subword assignment is not supported, but there's a pattern to do this:
Driven by the Chisel needs (for the moment, which is a subset of what everybody need)
With limited developers, we've got to prioritize what developers are willing to drive. Consequently, if there's some feature you desperately need... we'd love to get you as a developer and have you drive it.
Summarily, we really, really want you as developers! The current developers are either grad students or engineers who can't work on Chisel/FIRRTL full-time. If there's a feature that you want, please file issues, throw PR's at us, or attend developer meetings (currently Fridays 1300--1500 PST/-0700, skipping this week due to US Thanksgiving). I can get you more info about the latter if you need.
Alternatively, if you, your team, or your company has a great idea on a better or alternative way to do it, go build it! If you'd like to provide inter-operability with FIRRTL (or Chisel in some way) that'd be awesome, though. :blush:
@seldridge
About BB and async reset : Blackbox isn't a robust workaround for asyncronus reset, as with some technologies, the default is to use asyncronus reset. (I don't see myself using blackbox everywhere in my code base)
Also using blackbox for elements like FF is quite enoying, as you have to manualy drive all the signals of the FF, i mean, you can't infer the FF behaviour in a friendly way via if statements.
Using BlackBox for FF also break in part the possibility to reuse FIRRTL optimisation passes.
It would actualy also be painefull to import at none FIRRTL netlist which use as default asyncreset into FIRRTL. Which is part of the subject of this issue.
I agree that black box is a usefull tool, but registers are too important for it.
About Subword assignment
I know there is workarounds, but the issue here, is if we want FIRRTL to be a universal LLVM of hardware, we probably need to support this kind of feature.
General statement about hardware open-source tools I know that developping stuff require a lot of time, ressources are limited, and all that kind of things. But if we want to provide some quality tools to make everybody happy, if we realy want to make a viable alternative in that freezing hardware world, we can't stick to our personnal/projects needs, because that's just not good enough.
@Dolu1990: thanks for the feedback and thoughts!
- Yeah, BB/Async: this is the temporary solution. A more robust one is in the works. An RFC or discussion on the tracking issue about the API for this would be good.
- Maybe @azidar has some thoughts about subword assignment. It's difficult to think that subword assignment is a killer for an IR since it's a specification choice and the frontend needs to emit things to the spec. The mid-end/compiler doesn't care too much. I may be wrong, however. This is likely worth an RFC so that we can start evaluating options.
- Totally agree about open-source tools. On the Chisel/FIRRTL side we're trying to make it and the process as open as possible, attractive to users and developers, implement formal governance, etc. With the developers supporting it, we're not treating it as a personal project as we have users and companies (our own and others) depending on it. But, I (and the developers) have biases. If it's coming across as a personal project, tell us! :smile: If you have any feedback about this process, biases we're expressing, or ways that we can improve the developer interaction process, we'd be happy to hear it and try to address it.
Apologies for moving the discussion somewhat off-topic.
I think Verilog itself is the best HDL IR. It can be low level enough to become a netlist, or high level enough to be a human-readable-writable language. We just need to get standard AST representation of it and then develop lowering transformations when we can emit a valid Verilog in the middle.
