Would you want this be part of SymbiFlow?

[mithro]

Hi @rodrigomelo9,

This type of project seems like it would be an excellent addition to the SymbiFlow project. Did you want to join forces here?

The rest of the SymbiFlow project is using the following tools, so it would probably would be good to use them too? (a) Support using conda to get latest version of tools. Should also make it easier to test multiple versions too. (b) Use edalize for toolchain interfacing. Use FuseSoC for design integration.

Thoughts?

Tim "@mithro" Ansell

[rodrigomelo9]

Of course, would be great to be a Symbiflow project.

I used mainly Dockers and Python environments (I am not an expert on any of them) instead of Conda. But is not a problem to learn another tool.

FuseSoC is in my TODO list of project to learn, so what better than have a need? However, I am not sure that needed with current examples, maybe later.

About Edalize, you know, I am using PyFPGA. In fact, I am using an already developed CLI helper called fpga-hdl2bit, something similar to what you did with fpga-tool-perf. Maybe, this last could be used instead (I guess, with small modifications, that I already did in PyFPGA when starting this project).

Send me an email to see how to continue. Thanks.

[mithro]

@rodrigomelo9 It might be good to understand if there is a way to "merge" PyFPGA and edalize or if there is some fundamental difference which makes the two approaches incompatible? I'm sure that @olofk would love to have a lot more help developing edalize.

[rodrigomelo9]

I will take a deeper look into edalize. For what is done in this repo, I suppose that fpga-tool-perf can be enough.

[mithro]

fpga-tool-perf and fpga-hdl2bit might still want to be seperate tools -- they just could use the same backend libraries?

[rodrigomelo9]

Yes, of course, they could :-D

[eine]

Just chiming in to let you know that I'd love to be informed of any discussion regarding possible merging of any of the following projects:

• edalize/fusesoc
• pyfpga
• tsfpga
• PoC

All of them are written in Python and all seem to serve similar purposes, albeit with subtle and meaningful differences. As commented in https://github.com/ghdl/ghdl-yosys-plugin/issues/95#issuecomment-605212832, I feel this is a weak point of the community. It would be great to have a common forum where @olofk, @rodrigomelo9, @LukasVik, @Paebbels and others can discuss about the strength and weakness of their approaches. There has been some discussion during the last months in gitter.im/vhdl/General. Unfortunately, a chat room is not a good place to search for conclusions. At the same time, AFAIK all of them are busier than they'd like to. @mithro can you suggest some specific place to talk about this?

[mithro]

FYI - I have a "Python Libraries for EDA Toolchain Interfacing" document at http://bit.ly/pyfgpalibs

From what I can see edalize + fusesoc is the clear winner in terms of industry adoption. Both the https://chipsalliance.org/ and https://opentitan.org/ projects have adopted it and SymbiFlow is moving towards it being the suggested tool in this area. It also clearly divides the tooling interfacing from the SoC side of things.

[eine]

FYI - I have a "Python Libraries for EDA Toolchain Interfacing" document at http://bit.ly/pyfgpalibs

I was rather thinking about some issue and/or label in a GitHub repo, similar to SymbiFlow/ideas#19, as a complement to a report.

From what I can see edalize + fusesoc is the clear winner in terms of industry adoption. Both the chipsalliance.org and opentitan.org projects have adopted it and SymbiFlow is moving towards it being the suggested tool in this area. It also clearly divides the tooling interfacing from the SoC side of things.

I beg to differ, as I feel this is a context-biased statement. I agree that multiple metrics might lead to think that Verilog, edalize and fusesoc are clear winners in the industry, specially because the alliances/projects you mentioned (among others) are doing a relevant marketing effort. However, IMHO that's mostly a (interesting and still useful) transitory hype.

Open source tools (meaning yosys) supported Verilog first, and have supported it only, just because it is infinitely easier to parse than VHDL. The focus of yosys was never to write parsers for HDL languages. Actually, that's the same reason for SystemVerilog being much less supported than Verilog. Verilog was frozen 15 years ago, other languages were not.

As a result, edalize has been focused on Verilog only. Don't take me wrong, I have talked to @olofk about it, and I know that it is not a design restriction by any means. Nonetheless, the fact is that many open source projects have implicitly picked the idea that "you better use Verilog if you want to use open source tools", which is fundamentally flawed.

It is fundamentally flawed because most practical projects are not written in Verilog, for obvious reasons. Most of higher level generators can export either Verilog or VHDL. Some don't export any of them, but their custom intermediate representation (e.g. https://section5.ch/index.php/2020/03/20/myhdl-and-pyosys-direct-synthesis-using-python/). There are only a few which can export Verilog only (two that I can think of: Chisel and BSV).

On the other hand, despite not receiving so much attention, VHDL is in a healthy state (https://blogs.mentor.com/verificationhorizons/blog/2019/01/15/part-6-the-2018-wilson-research-group-functional-verification-study/). This is true not only in Europe. As an active contributor of VUnit, I talk to multiple users from America too (from USA to Argentina) which do use VHDL as their main language. I feel that most of them have not stepped out to the open source EDA community because they are being implicitly excluded (meaning, not being actively called to join).

Fortunately, GHDL is a 15-20 year old tool that, being open source, is the de facto standard. It is used in the Industry (officially or not), in Academia and by the VASG (even to test new language features). Tristan did (and is still doing) an undescribable effort to allow synthesis through GHDL during the last year and a half. This fact is so meaningful for the open source EDA community and for the EDA industry as a whole. Because writing a good VHDL parser is so hard, he is the only one that succeeded so far. No open source project can compete, and many vendor tools are clearly worse.

Since formal synthesis with GHDL + yosys was reported last august-september, and since microwatt was synthesised last january, the activity around it is thriving. Very specially, there are lots of requests that involve VHDL 2008 features, which are precisely not well supported by vendor tools. This is mostly because GHDL's synthesis features allow multiple different use cases:

• Pre-processor of modern VHDL sources to generate a plain old VHDL source that vendor tools can accept.
• Open source frontend for yosys.
  • Mixed-language (meaning VHDL-Verilog) synthesis and post-synthesis simulation.
• Open source frontend for other technology synthesizers/mappers.
• Formal verification with PSL.

Overall, I think that advertising VHDL support in open source EDA tooling at least as much as Verilog has been advertised would be so beneficial for the community. Apart from the most obvious reason of allowing better collaboration through mixed-language projects, users that want to learn HDL would freely choose the language. AFAIK, verification in Verilog needs to be done in SystemVerilog and no open source simulator for SV exists. Conversely, verification frameworks in VHDL 2008 exist, and can be used with GHDL.

Anyway, the point I'm trying to make is that there is a de facto divide in the community between open source tools for Verilog and VHDL, and I believe that we should break that barrier, not try to force people to switch sides. As a matter of fact, PoC was created in 2015, and it could have been extended, instead of creating edalize in 2018. Maybe Olof just didn't know about it. Whatever the reason, it's ok. At the same time, tsfpga was created before edalize and it was used internally in the industry; but it was published later. There was no synergy at first, because tsfpga was based on VUnit and focused on Vivado, while edalize was independent and focused on multiple tools (open source at first). Apart from those, we do know of several companies that have their own project management frameworks built on top of VUnit to fulfill the purpose of edalize. Those are not public or open source, but there is interest in the community on putting something together and contributing pieces or implementing them again. Some public examples are TerosHDL, which uses VUnit's dependency scanner, and VUnit Test Explorer.

From a technical point of view, the main difference I find is that edalize/fusesoc are almost purely declarative tools, while PoC/VUnit/tsfpga are rather imperative. To be specific, edalize's integration of VUnit provides a more cumbersome file declaration UX than using either VUnit alone or tsfpga. Hence, we cannot tell all the VHDL user base to just switch the tools because "the industry" decided it. We would be telling them to heavily refactor all their toolchains for no obvious benefit. Instead, I believe we should stress which are the features that edalize (or any other selected tool) needs to fulfill, so that we can invite users that for any reason, don't find it appealing enough. This needs to be a relaxed and thoughtful discussion, because most of the wheels are already rolling, and companies rely on them.

[mithro]

Couple of short responses;

Because writing a good VHDL parser is so hard, he is the only one that succeeded so far. No open source project can compete, and many vendor tools are clearly worse.

That is a bad sign for VHDL, languages are generally much healthier when there are multiple independent usable implementations.

As a matter of fact, PoC was created in 2015, and it could have been extended, instead of creating edalize in 2018. Maybe Olof just didn't know about it. Whatever the reason, it's ok.

FYI -- edalize was split out of FuseSoC to make it clear you could use the tooling interfacing independently of core composition side. The first commit to FuseSoC was by Olof Kindgren on Aug 30, 2011, making it a good 4 years older than PoC, so it seems more like PoC didn't know about FuseSoC.

It is fundamentally flawed because most practical projects are not written in Verilog, for obvious reasons.

FWIW - This doesn't match my experience.

There are only a few which can export Verilog only (two that I can think of: Chisel and BSV).

As far as I can see, only MyHDL seems to support VHDL?

Chisel and BSV are probably the two biggest open source HDL generators out there at the moment. Then at the next level you have groups like the Migen / nMigen / LiteX ecosystem which also don't generate VHDL.

From a popularity point of view -- Chisel has 1.3k stars, the BlueSpec compiler (which is less than 2 months old) has 265 stars, while LiteX has 500 stars compared to VUnit's has 358 in comparison.

Instead, I believe we should stress which are the features that edalize (or any other selected tool) needs to fulfill, so that we can invite users that for any reason, don't find it appealing enough.

I think everyone would love to see more VHDL support in the open source tooling.

However, it really needs the people who are actively using VHDL and care about it to step up and either do the development themself or contribute funding to have others work on it for them.

The work around microwatt has been a great of example of actual movement here. I believe microwatt is already FuseSoC enabled too (adding to the idea that FuseSoC is continuing to gain traction everywhere).

As you mentioned, I'm sure that @olofk would love to merge pull requests that improves support for VHDL tools in edalize.

[eine]

That is a bad sign for VHDL, languages are generally much healthier when there are multiple independent usable implementations.

I would not like to argue which language is better or worse, because my point is that neither Verilog or VHDL are going anywhere in the short-mid future. However, should we have to compare them, VHDL 2008/2019 corresponds to Verilog + SV, while Verilog only corresponds to VHDL 1993/2002. In this sense, I'd say that open source tooling for Verilog and VHDL 1993 are well developed already, while SV or VHDL 2008 are not so.

Regarding the healthiness, other many solutions exist (rust_hdl and PyVHDLParser being two notable). However, not all of them do semantic analysis apart from tokenisation, or other elaboration related stages of a "complete parser", or not all language features are supported. I believe the state of SV is very similar.

FYI -- edalize was split out of FuseSoC to make it clear you could use the tooling interfacing independently of core composition side. The first commit to FuseSoC was by Olof Kindgren on Aug 30, 2011, making it a good 4 years older than PoC, so it seems more like PoC didn't know about FuseSoC.

Thanks for clarifying. I was convinced that interfacing multiple EDA tools was an independent afterthought. Anyway, as said, whatever the reason/order, it's ok. The point is what we can do now that multiple users depend on different existing and overlapping tools, given that collaboration was not done from the beginning.

FWIW - This doesn't match my experience.

That's the point. The EDA industry is very fragmented and context/environment/ecosystem dependent in terms of languages. That didn't change in 30 years, I don't believe it will (towards Verilog) in the next decade.

As far as I can see, only MyHDL seems to support VHDL?

SpinalHDL, Clash, HLS/SDSoC/SDAccel/Vitis, HDL Coder, hwt, etc. can generate VHDL.

From a popularity point of view -- Chisel has 1.3k stars, the BlueSpec compiler (which is less than 2 months old) has 265 stars, while LiteX has 500 stars compared to VUnit's has 358 in comparison.

As a matter of fact, GHDL (which is 15-20 years old) has ~1k stars (on GitHub). And OSVVM, which is reported as "the #1 VHDL Verification Methodology" has ~100 stars (on GitHub). However, I would not want to base a discussion on poor/partial metrics. The demographics of users of the various projects are absolutely different. There is a market for all/any of these projects/languages, that's why all of them are alive and being actively used. Unarguably, the most used (with a huge difference), written, generated or reused, are Verilog and VHDL. By supporting both of them, almost all higher-level tools are suitable.

The work around microwatt has been a great of example of actual movement here. I believe microwatt is already FuseSoC enabled too (adding to the idea that FuseSoC is continuing to gain traction everywhere).

I think this is not a fair point, because Olof himself did add support for FuseSoC to microwatt. I guess that many projects (e.g. this one) would love that, but it is not a feasible solution.

Actually, Anton, the author of microwatt, did not use edalize in ghdl-yosys-blink, even though he had a working example in his own repo. By the same token, examples in ghdl-yosys-plugin are using makefiles, although Tristan asked Olof about FuseSoc a few days ago in gitter.im/vhdl/General.

I think everyone would love to see more VHDL support in the open source tooling.

I believe the main point is that (at least partial) VHDL support in the open source tooling exists, and it is increasing. However, those are projects advancing in parallel to SymbiFlow's selected tooling. If users want to use SymbiFlow's tooling, they are encouraged to use a different language or to write the tools. That's fair. However, it is equally fair to ask SymbiFlow to slighly widen the scope, to gather the wider open source EDA community. I think that, now that open source synthesis of VHDL is possible, we are at a sweet point to revisit some foundational ideas.

However, it really needs the people who are actively using VHDL and care about it to step up and either do the development themself or contribute funding to have others work on it for them.

Most of the people I know are actively doing the development themselves. However, they choose to start something from scratch (as this repo or pyfpga) or they do their work based on projects other than edalize/fusesoc. I believe this is what this discussion is about. How can we revert that trend? Actually, I've spent the last months talking with the maintainers of the various projects I mentioned, and I feel that we are missing a path to follow. That's why, after getting to kind of understand the state of the community, I'm discussing these issues here. For instance, is there any folder, diagram or page where users can find all these GDocs and what's the relation between them?

IMHO a good starting point would be to pick two examples: one very simple (blink, counter, UART loopback), another one slightly more complex (instancing some PLL/MCMM). Then, write both of them in multiple languages/generators and invite maintainers of different projects to help setup them with multiple tools. That would hopefully provide a neutral ground to learn/compare the capabilities of each solution and hopefully agree on merging features. In fact, I believe that much of this content exists already, but it is spread and hidden, so a single user needs to invest a not small amount of time learning about each tool. Does SymbiFlow have any such "demo repository to test all the supported toolchains"?

EDIT

https://star-history.t9t.io/#ghdl/ghdl&VUnit/vunit&OSVVM/OSVVM&freechipsproject/chisel3&B-Lang-org/bsc&enjoy-digital/litex&SpinalHDL/SpinalHDL

[mithro]

If you want to chat with people working on SymbiFlow, my suggestion is to join the #symbiflow IRC channel (or if you want slack).

Most of the SymbiFlow Google Docs are in a folder here. The SymbiFlow project is trying to move stuff out of Google Docs into Sphinx + ReadTheDocs. See symbiflow.rtfd.io

If you want to help improve SymbiFlow support for VHDL, the first step would be to improve it in edalize. edalize is what SymbiFlow will be promoting and using going forward in all the SymbiFlow documentation and tooling.

FYI -- There are multiple big companies that are actively funding developers to work on FuseSoC, edalize and improving the Verilog + SystemVerilog story in the open source world. If you know anyone who wants to help fund VHDL please do put them in contact with me. The only company I know of who slightly cares about VHDL in open source tooling is a few people at IBM.

[rodrigomelo9]

Some comments and I will manage the issues in other tickets :P

I started in the FPGA world in 2006, with FPGAs from Xilinx, using ISE and GHDL. I practically used only that until 2015, where there was a change in my work. From there, I started to work with other FPGA vendors, tools and also languages, such as Verilog. Before 2015, I used some scripts developed by my boss until there, written in Perl, which only supports ISE. In 2015, I started FPGA Helpers, which based on a Makefile and two Tcl, supported ISE/Vivado, Quartus and Libero-Soc in 2016. In 2019, I worked in a Verilog based project using hdlmake to interface with Quartus. Where needed some patches to support exactly what needed, but I didn't recommend FPGA Helpers, because the people which I worked with, like the idea of only one Python file (Manifest.py). In October 2019, I decided to change in favour of PyFPGA, where the entire project could be solved in a unique file if desired.

I found edalize at the end of 2019, when PyFPGA was already written, and you know, it is my baby :P I realized in January that nMigen can do synthesis and the rest of the Flow from Python scripts, and I learned yesterday about tsfpga and PoC (I know about PoC since before, but not about they solved this same problem).

The point? Is really difficult to know what is available, where, in what state. You need to be very embedded in the community, in a lot of chat rooms, in a lot of projects, reading a lot of issues :P, to be updated.

I decided to be involved in last December when I read about Yosys support of Spartan 6 devices (https://github.com/YosysHQ/yosys/issues/448), and was awesome to know also about the work in ghdlsynt-plugin (ghdl-yosys-plugin now). I really want the mixed support of HDLs.

I agree with a unified library to interface with the EDA tools and several projects which implements what they need. I will use edalize to implement the needed tool in this repo, but because it is used by the Symbiflow project. I agree that could be useful:

• A place where the persons related to a similar project could discuss if they can be merged/unified, or share a common library.
• Examples of the same problem solved with each tool. And nobody will provide a better example than the person which developed the tool :P

Regards, and let me say that I really appreciate this interchange of ideas, but I don't want a war between VHDL and Verilog open-source communities, I want an HDL open-source community working together, and I know that you also :-D

[mithro]

I'm leading the SymbiFlow project to try and do the following;

• Pull together tools into a more unified "flow" (IE A "one stop shop")
• Provide a "clear way of doing things" that beginners can follow
• Push forward the current state of the art
• Provide a corporate friendly face to allow companies to directly fund things they care about.

We are still a long way from having all that but we continue to push forward here. I think the work that @rodrigomelo9 is doing here is essential to helping us understand the compatibility

As @eine mentions VHDL is used by a non-insignificant part of the industry, so having VHDL support in the SymbiFlow flow is something we do want to have VHDL support.

However, we also only have limited resources and the sponsors funding developer time are currently only interested in Verilog and SystemVerilog based tooling (it is why things like sv-tests now exist). As these sponsors are willing to put their money forward it means that Verilog / SystemVerilog is going to be better supported and have more development in SymbiFlow. (FYI -- I have been trying to convince IBM to fund more VHDL work but they haven't bitten yet, if you know any other companies I should be targeting please do share them!)

Due to not having any direct funding at the moment, it is thus important that VHDL take advantage of common tooling even if it isn't the best fit. (In fact if you are using the same flow and tooling that Verilog developers use you may even find some might switch to VHDL because it does seem to be a better language :-). ). ghdl-synth being integrated with Yosys as a plugin is actually a really good example of the VHDL developers making good usage of stuff originally targeting Verilog.

The point? Is really difficult to know what is available, where, in what state. You need to be very embedded in the community, in a lot of chat rooms, in a lot of projects, reading a lot of issues :P, to be updated.

I too identified this problem and hence are trying to fix it with the SymbiFlow project. In the mean time @drom has some pretty cool index repositories see https://github.com/drom/awesome-hdl (based on the concept of https://github.com/sindresorhus/awesome).

[eine]

Thanks for bringing hdlmake. I completely forgot about it. Actually, I believe an analysis of edalize and hdlmake would be so interesting.

I learned yesterday about tsfpga and PoC (I know about PoC since before, but not about they solved this same problem).

I suggest you chat with @Paebbels about the multiple features of PoC that are not seen at first glance. It is a really powerful framework that handles many complexities and details. However, the learning curve is steep. Fortunately, he is open to refactoring some parts and/or spliting them to separate repos, should it allow to better interact with other projects in the ecosystem. Independently of whether some collaboration is possible or not, I believe that the discussion would be enriching.

The point? Is really difficult to know what is available, where, in what state. You need to be very embedded in the community, in a lot of chat rooms, in a lot of projects, reading a lot of issues :P, to be updated.

A couple of months ago, we created organisation hdl as a superset/complement of vhdl. The main motivation to do so was to merge multiple existing "awesome lists": https://github.com/hdl/awesome. Unlike existing formats, where a single markdown file is used, we wanted to use a separate markdown file with metadata for each tool/project/resource. That would/will hopefully allow easier machine manipulation of the data to support more user friendly search frontends (given the huge amount of existing info). https://hdl.github.io/awesome/ was/is a prototype of a possible visualisation. Unfortunately, the idea didn't gather any attention at all. Guess that documenting/explaining our work is not a strong point of the open source HDL community... Plus, I acknowledge that the prototype frontend is not the most attractive... Maybe after this discussion we can push it again.

I really want the mixed support of HDLs.

Not for simulation yet, but for synthesis @hackfin is doing an interesting work. Check his issues in ghdl/ghdl and ghdl/ghdl-yosys-plugin.

I agree that could be useful:

• A place where the persons related to a similar project could discuss if they can be merged/unified, or share a common library.
• Examples of the same problem solved with each tool. And nobody will provide a better example than the person which developed the tool :P

Shall we create a hdl/toolchains, hdl/examples or hdl/demos project? Once we agree on the example/demo designs, I can contribute:

• GHDL:
  • Simulation with a bash script or a Makefile.
  • Cosimulation through VHPIDIRECT with a bash script or a Makefile.
  • Dynamically loading GHDL simulations from foreign languages.
  • Synthesis with ghdl-yosys-plugin (native/containerised) with a bash script or Makefile.
  • Synthesis with --synth as a preprocess step for vendor synthesis tools.
• VUnit (Python):
  • Simulation with GHDL, ModelSim/QuestaSim, RivieraPRO, ActiveHDL.
  • Cosimulation through VHPIDIRECT with GHDL.
  • Synthesis with native/containerised open source tools through GHDLSynth.py.

EDIT

Regarding synthesis support of Verilog, you might find verismith interesting.

[mithro]

I suggest you chat with @Paebbels about the multiple features of PoC that are not seen at first glance. It is a really powerful framework that handles many complexities and details. However, the learning curve is steep. Fortunately, he is open to refactoring some parts and/or spliting them to separate repos, should it allow to better interact with other projects in the ecosystem. Independently of whether some collaboration is possible or not, I believe that the discussion would be enriching.

From what I can see PoC is closer to FuseSoC than edalize right? Maybe PoC can look at trying to use and/or improve edalize as the backend.

A couple of months ago, we created organisation hdl as a superset/complement of vhdl. The main motivation to do so was to merge multiple existing "awesome lists": https://github.com/hdl/awesome. Unlike existing formats, where a single markdown file is used, we wanted to use a separate markdown file with metadata for each tool/project/resource. That would/will hopefully allow easier machine manipulation of the data to support more user friendly search frontends (given the huge amount of existing info). https://hdl.github.io/awesome/ was/is a prototype of a possible visualisation.

I recommend you join forces with @drom here. I believe @drom's list at https://github.com/drom/awesome-hdl is already more comprehensive then the one at https://github.com/hdl/awesome?

VUnit (Python):

Could VUnit look at using edalize for the toolchain interfacing? If it doesn't work currently we should look at what needs to be improved in edalize to make it possible for VUnit to use edalize.

[mithro]

Makefile is a good option for people who don't want a dependency on Python (I love Python, but not everyone wants to depend on it). I think hdlmake might fit the bill there?

[rodrigomelo9]

Well, PyFPGA is for people who want the Python dependency :-P

I love Makefiles, I use them a lot (this project is mainly based on Makefiles :-D), but, in my experience, are not for everybody. And I dislike having several supporting files, with no real information, so I prefer a small Python script for my projects.

With hdlmake you have a file called Manifest.py with variables which must be filled, to produce a Makefile... (which you need to regenerate if there are changes).

I think that there is not a best option, because is personal.

[rodrigomelo9]

@eine

Shall we create a hdl/toolchains, hdl/examples or hdl/demos project? Once we agree on the example/demo designs, I can contribute:

I can contribute with PyFPGA examples. To me could be a great thing.

[olofk]

Wow, this was a long thread already.

Anyway, to answer some things. Edalize was split out from FuseSoC because I realized it served two functions, and there were other projects that partly implemented this. By defining an interface (EDAM) between the frontend and backend, my intention was to allow other projects to be plugged in on either side. When I started the effort of creating an interface I reached out to all tool maintainers that I thought would be interested in this (hdlmake, vunit, apio, kactus2 and a bunch more) to get some help creating this interface and avoid duplication by having a common interface. I have been asking around for the same thing when it comes to programming tools. Currently, Edalize, migen, Apio and other projects all have support different subsets of tools for uploading the bitstreams to FPGAs. I would love to have a common library for this that everyone can use instead.

As for PoC, Patrick and I have been talking a lot about this some years ago and the intention (from his side and mine) was always to try and package PoC as one or several FuseSoC packages. I started working on this but never had time to finish it up. Some help would be appreciated.

As for VHDL, FuseSoC has supported both from day one! I'm currently working on a masssive VHDL project using FuseSoC and I'm slowly upstreaming FuseSoC support for CERN's collection of cores at ohwr.org. There are plenty of other VHDL users that use FuseSoC and Edalize too

We also did have a meeting with many of the maintainers of Python-based tooling at ORConf 2018 where we hoped to find some areas to collaborate. There was a document procuded, but I don't think anything tangible every came out of it. The usual problem was probably that everyone was too busy working on their own thing.

As for other HDLs (Chisel, SpinalHDL, Migen, Myhdl, Clash), there is a difference between them and Verilog/VHDL. They are not natively supported by any tools and must be converted through verilog/vhdl. That's why FuseSoC/Edalize don't have native support, but thanks to the generator system, it is possible to convert designs in other languages on-the-fly to create verilog/vhdl representation. I have done this to create standalone DDR controllers from LiteDRAM and I'm hoping to find time to do the same for other migen cores as well, and for Chisel things like rocket

[hackfin]

Not sure why I got CCed on this thread, I don't know all the tools mentioned here. Throwing in a bit of insight from the Python MyHDL section:

As for other HDLs (Chisel, SpinalHDL, Migen, Myhdl, Clash), there is a difference between them and Verilog/VHDL. They are not natively supported by any tools and must be converted through verilog/vhdl.

Hopefully, there'll be some usable direct synthesis through MyHDL/pyosys ready in a few months. First experiments look good, but there's some revamping on the framework to do WRT hierarchy extraction. The Verilog transfer will certainly remain for a while (for co-verification). And for other synthesis tools (closed source) VHDL transfer turned out to be the most robust way to verify signal processing pipelines (something, where Verilog happens to be less explicit). So there are no big game changers expected..

But for future extensions (like describing formulas the HLS way) the Pythonic way is very interesting und super efficient for different modelling approaches. Creating a classic V* HDL from that and going back to synthesis is a complicated and nasty inference guessing dance, it's easier to synthesize a DSP pipeline directly. Plus when all the regress testing comes in, the Python approach as the universal glue is just not to beat.

For the entire toolchain however, I'm still inclined to think that a build system is still best based on the 'make' standard, although Python could probably do better. Just haven't seen the perfect Makefile replacement yet (it will have to be as atomic as git...I guess).

[mithro]

FYI - nmigen by @whitequark also does the Python directly to Yosys RTIL (and then uses Yosys to generate Verilog if needed) -- I think it shows how an open source tool like Yosys is already starting to change a lot of the way people are thinking about how to do high level HDL languages!

[rodrigomelo9]

The rest of the SymbiFlow project is using the following tools, so it would probably would be good to use them too? (a) Support using conda to get latest version of tools. Should also make it easier to test multiple versions too. (b) Use edalize for toolchain interfacing. Use FuseSoC for design integration.

I am using docker which seems more suitable, as we agreed in #10.

I am using the tool fpga-hdl2bit. It is developed using PyFPGA. Maybe, someday PyFPGA could use edalize to interface with the tools, but I think that it is external to this repository. More info in #9.

I close this issue because is too long and without clear steps to follow. It would be great to join forces with the SymbiFlow project, let me know @mithro if you are still interested and what to do. Regards