XVilka
commented
6 years ago Open XVilka opened 6 years ago
XVilka
commented
6 years ago 
mx-shift
commented
6 years ago 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 notifications@github.com 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 .
mithro
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago @Nic30: good points.
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
commented
6 years ago @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 notifications@github.com 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 .
dvc94ch
commented
6 years ago 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 <notifications@github.com 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 < notifications@github.com> 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 .
Nic30
commented
6 years ago @kc8apf why are you not using ANTRL4 C++ runtime?
Nic30
commented
6 years ago @dvc94ch Is it possible to have more than single clock domain in current FIRRTL?
dvc94ch
commented
6 years ago 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 <notifications@github.com 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 .
XVilka
commented
6 years ago 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 <notifications@github.com 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 <notifications@github.com 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 .
seldridge
commented
6 years ago @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
commented
6 years ago 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 <notifications@github.com 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 .
mithro
commented
6 years ago 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
commented
6 years ago 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 <notifications@github.com 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 .
dvc94ch
commented
6 years ago @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.
Nic30
commented
6 years ago @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.
Nic30
commented
6 years ago 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.
XVilka
commented
6 years ago 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.
Nic30
commented
6 years ago @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.)
kraigher
commented
6 years ago 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.
XVilka
commented
6 years ago 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."
christiaanb
commented
6 years ago 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:
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.
XVilka
commented
6 years ago Apart from missing asynchronous resets there are also these issues in FIRRTL (by @Dolu1990 in https://github.com/SpinalHDL/SpinalHDL/issues/158#issuecomment-440996391 ):
myWire(4 downto 2) := miaou
Dolu1990
commented
6 years ago In short, this is a common issue with Chisel/FIRRTL : freechipsproject/firrtl#219 => low priority
it realy annoys me.
seldridge
commented
6 years ago 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.
Yes, Chisel and FIRRTL do not natively support asynchronous resets. There's tracking issues about this on the Chisel repository here:
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)
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:
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:
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:
Dolu1990
commented
6 years ago @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.
seldridge
commented
6 years ago @Dolu1990: thanks for the feedback and thoughts!
Apologies for moving the discussion somewhat off-topic.
drom
commented
6 years ago 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.
Dolu1990
commented
6 years ago @seldridge <3 ^.^
So about the subword assignement, it's all about making easy to export things into the FIRRTL format without too much transformation. Getting from a netlist with subword assignement to one without it require some quite specific transformations. It's not a IR killer, i agree.
About the community aspect, that's great, it's realy a good thing to open the developpement.
@JohnDMcMaster But the event driven paradigm add a lot of noise which has nothing to do with an digital logic hardware netlist, does it ?
I mean, if i look at FIRRTL and Verilog as a IR, that's the main thing which appear to me. So, that's maybe one thing to talk about.
dvc94ch
commented
6 years ago The last time I tried doing some fpga design, I wasted a bunch of time trying to get migen to generate verilog that verilator would not complain about and then my changes where basically not accepted because every time you make a change 10 other verilog tools start chocking on it. At that point I think I may aswell just write verilog in a way that works for the tools I'm currently using. So all that using verilog as an ir means that we can just aswell give up on writing any other hdl's and just continue using verilog. The upside is we don't need an ir either so a lot of work saved.
seldridge
commented
6 years ago @JohnDMcMaster: I've thought that Verilog as IR is tractable if you define a very restricted subset of Verilog as the IR. This has the plain difficulty of parsing the Verilog and dealing with all the complicated legacy Verilog semantics that live on due to it's history as a parallel event language. E.g., Verific Design Automation makes money just selling Verilog/VHDL parser licenses. An analogous approach would be to use a restricted subset of C/C++ as program IR. It's tractable, but likely difficult.
Relatedly, I've used Verilog-Perl to write transforms on FIRRTL generated Verilog. This only worked because of the low-level, IR-like nature of the output Verilog. This approach breaks down if you try to get it to work on arbitrary input Verilog/SystemVerilog that exercises all language features.
I've then personally concluded that defining a clean circuit IR was a better approach.
(Unrelated note @JohnDMcMaster: I've always thought WaveDrom was super neat!)
@dvc94ch: Verilog design freedom would still exist, even in the presence of an IR. Excusing another software analogy: if you want to write an interrupt service routine using assembly because that gives you the control you need, that should work and continues to work. The utility of program IR comes when building compilers for high level languages targeting assembly. However, if you want to try to optimize assembly, inline assembly, or do interprocedural/link-time optimization, a frontend can read that assembly into program IR and work with it. Summarily, if Verilog works, use it! :+1:
dvc94ch
commented
6 years ago Well I think I've given up on fpga's. There is plenty of fun software to write that doesn't have to do with fpga's. and my point was that a high level language has different semantics than the assembler. migen's semantics for example are intimately tied to verilog's.
Nic30
commented
6 years ago I think Verilog itself is the best HDL IR.
@drom hdlConvertor I tried to. It has no use as intermediate language because raw Verilog does not fit well into graph database. Also Verilog has many it's own problems. f.e. ROM has to be written as switch statement in old versions etc.
But you have the point. We do not need to have new language, we need unified API to represent HDL, parse it and perform manipulations over it.
I would like to use some sort of serializable in-memory graph database. But there is not any suitable known to me. (Things like Neo4j are too slow and not optimized for HDL)
Also parsing of VHDL is incredibly slow, Verilog is faster, but still...
@seldridge If we cant have an async resets/latches/falling edge regs, can we at least add black-boxes into FIRRTL library? (It seems to me that there is a problem. You can not specify the data-width for such a blacbox.) Because otherwise FIRRTL can not be used for development of IO and it's usability for Intel FPGAs is limited. Also this seems to me like a best compromise for everyone which does not break anything. I think that sooner or later you would be forced to add it anyway. F.e. ARM SoCs have many async. transitions. And it is only question of time when you really will have to write this in Chisel and you will have to use latches.
As you say it is not hard to create your black box and import it but how can automatic analysis work when everyone has many black box entities in own design? How are things compatible then? Will the HDL be copied every time the Verilog is generated? Can there be a name collision? Is name colision checked when FIRRTL -> Verilog collision?
@dvc94ch We are not doing it because it is easy. There are project which can choose ASIC or FPGA because other option does not exists. And question now is how do we seed up HW development.
migen's semantics for example are intimately tied to verilog's
I also see this a problem. But they are satisfied.
mx-shift
commented
6 years ago My desire for an IR is to have something that is fairly simple and straightforward to translate to a variety of FPGA architectures and ASIC cells. Verilog and VHDL are much higher-level and would be implemented in terms of the IR similar to how C and Rust are implemented in terms of LLVM IR. BLIF is much closer to what I'm imagining.
I can see a desire for an even higher-level IR that offers additional, common constructs. HDLs might target that high-level IR and a common set of transforms translate it to the low-level IR. That way every HDL frontend doesn't have to reinvent an adder and backends don't need to recreate how to construct one out of LUTs. Another way to think about this is a standard library for the low-level IR.
On Thu, Nov 22, 2018, 10:44 AM Aliaksei Chapyzhenka < notifications@github.com wrote:
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.
— 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-441102489, or mute the thread https://github.com/notifications/unsubscribe-auth/AJBDl0JCY9NcGWrM6yEQIWdXF9D05Gu1ks5uxvCEgaJpZM4YmSht .
seldridge
commented
6 years ago @seldridge If we cant have an async resets/latches/falling edge regs, can we at least add black-boxes into FIRRTL library? (It seems to me that there is a problem. You can not specify the data-width for such a blacbox.)
To clarify, you can have async resets, latches, falling edge registers... just not yet. These are planned to be implemented, just these are feature requests at this point.
FIRRTL does have blackboxes via the ExtModule IR construct. This allows you to instantiate a module and not define it. This can be filled in by a Verilog BlackBox (possibly parameterized) or via inline compilation. E.g., you can use Chisel (or Magma, etc.) to generate FIRRTL/Verilog or define what this is.
Because otherwise FIRRTL can not be used for development of IO and it's usability for Intel FPGAs is limited. Also this seems to me like a best compromise for everyone which does not break anything. I think that sooner or later you would be forced to add it anyway. F.e. ARM SoCs have many async. transitions. And it is only question of time when you really will have to write this in Chisel and you will have to use latches.
Latches as an explicit construct have been discussed, just not implemented. The question here is the API.
As you say it is not hard to create your black box and import it but how can automatic analysis work when everyone has many black box entities in own design? How are things compatible then? Will the HDL be copied every time the Verilog is generated? Can there be a name collision? Is name colision checked when FIRRTL -> Verilog collision?
Lots of questions. Analysis with blackboxes is difficult because the analysis can't look inside into an ExtModule. Granted, most of what you need for digital design is available. The intent is to fill out both the Chisel-level API and the backing FIRRTL support so that you have a full toolbox to build whatever you need. Blackboxes fill that hole while things are being implemented.
ExtModules would only be defined once, not multiple times.
There's extensive support in FIRRTL for avoiding name collisions during lowering (flattening aggregates) as well as for generating temporaries, etc. There's internal APIs for making it easy for transform writers to get it right.
FIRRTL collisions with Verilog keywords is taken care of, e.g., a FIRRTL module named always (I wrote that transform). FIRRTL name collisions with ExtModules are taken care of by looking at the port names (which is enough to clear name collisions). Collisions during module inlining or flattening are also taken care of (I took care of a refactor that makes sure this works correctly).
rochus-keller
commented
6 years ago I think Verilog itself is the best HDL IR.
Agree. But then I would highly recommend to restrict it to Verilog 2005 or 2001 (or even a defined subset of IEEE 1364), with no SystemVerilog protuberances.
EDIT1: Does anyone remember IEEE Std 1364.1-2002? That was a standardized subset of synthesizable Verilog RTL and - from my point of view - pretty much suited for IR. It was superseded by IEC 62142-2005 which was unfortunately withdrawn too.
EDIT2: Does anyone remember EDIF (Electronic Design Interchange Format)? It's based on S-Expressions (like Lisp) to store netlists and quite a bit simpler to parse. There are even a couple of standards for it: EIA-618, IEC 61690-1 and IEC 61690-2.
Nic30
commented
6 years ago @rochus-keller
EDIF
I know some tools can use it, but there is a problem, there have to be explicit instances for example for adder. The result is more or less target technology locked. I do not think that we can maintain support for all FPGAs and ASIC manufacturing processes.
EDIF readability is a joke. It does not support more files and is quite large. I mean EDIF is way to hell blessed by Xilinx and others back in 2005 if I remember correctly.
rochus-keller
commented
6 years ago EDIF - The result is more or less target technology locked. I do not think that we can maintain support for all FPGAs and ASIC manufacturing processes.
You seem to mix up the format with some unfortunately bad implementations. I actually mentioned EDIF primarily because BLIF was already mentioned in the discussion and both have overlapping concerns and can be converted to each other. I would still vote for a precisely defined subset of Verilog.
Nic30
commented
6 years ago Ok, it seems to me that many people want to use Verilog from various reason. Can someone create specification which features of Verilog can be used to make it ~equivalent with FIRRTL so potential conversion can be performed?
Also how to import the peoples which are working on HDL generators that they should use this?
Dolu1990
commented
6 years ago The issue i have with Verilog as a IR that you can work on is :
Nic30
commented
6 years ago @Dolu1990
Maybe IR should be really low level language and the "abstract" transformation phases should be part of the library.
Also it is required what "abstract" transformation phases are. For example this transformations is possible to implement in library for generating of IR and it is not required to have support for this in IR.
Would you add any other?
rochus-keller
commented
6 years ago I had a quick look on Google and found this link: http://www.iuma.ulpgc.es/~nunez/clases-FdC/verilog/Verilog-IEEE-1364.pdf. Maybe you want to have a look at it as a starting point. You find the syntax diff to VL 01 on page 29. Probably it's possible to kick out even more things and to make use of attributes for higher-level information. A cross-correlation with FIRRTL seems to be quite some effort.
Nic30
commented
6 years ago @rochus-keller I did not meant to choose Verilog standard but to choose which parts are useful and required.
For example preprocesor directives (‘ifdef and others) are useless. Parameters are not preset in FIRRTL, simulation part of Verilog and syscalls are also useless as well as unsynthetizable subset of Verilog. Also there are multiple ways how to describe something, which is also wrong because it increases complexity of analysis.
rochus-keller
commented
6 years ago Have a look at it first. It's not the full Verilog standard, but IEEE Std 1364.1-2002, a defined synthesizable subset. From my point of view it's a good starting point for an even more stripped-down version.
dvc94ch
commented
6 years ago I don't understand what is gained from this. Yosys already takes verilog does transforms on it and emits verilog again.
rochus-keller
commented
6 years ago Yet another good reason to stay with Verilog and not to switch to the academic flavour of the month.
Nic30
commented
6 years ago @rochus-keller RISC-V and Chisel3 (including FIRRTL) seems to you as academic flavour of the month?
@dvc94ch Thank you for the information, I was thinking that Yosys also use only subset of Verilog. I will look into it.
Dolu1990
commented
6 years ago When i look my calendar, i can see that we are nearly in 2019, and we are still facing VHDL/Verilog as glorified industry standard. This is depressing XD
lavour of the month.
@rochus-keller That's overstated XD
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:
Needs of the particular projects:
Chisel3
HWT
magma
MyHDL
SpinalHDL
Veriloggen
Yosys
Updates from https://github.com/SymbiFlow/ideas/issues/19#issuecomment-441382660 and https://github.com/SymbiFlow/ideas/issues/19#issuecomment-441619546