search

eine / vhdl-cfg

Playground to explore and compare how configuration is handled by different tools for development of VHDL projects
10 stars 2 forks source link

Current status #1

Open eine opened 3 years ago

eine commented 3 years ago

Coming from rodrigomelo9/FOSS-for-digital-HW-design#1

Regards https://github.com/eine/vhdl-cfg, I thought about something similar between PyFPGA and others, such as edalize, hdlmake, tsfpga, and so. The problem is, in my opinion, that a developer of the project must be in charge of the example. In another situation, it could be not a fair comparison.

@rodrigomelo9, agree. My original intention was to start with the examples from ghdl-yosys-plugin (see https://github.com/eine/vhdl-cfg/tree/master/modules and https://github.com/ghdl/ghdl-yosys-plugin/tree/master/examples), because those are the ones I'm most familiar with.

The first attempt was writing https://github.com/eine/vhdl-cfg/blob/master/GHDLSynth.py as a Python equivalent to existing Makefiles. The most relevant difference between this and other solutions is that GHDLSynth.py allows executing each step either natively or in a separate (docker/podman) container. That's something I borrowed from @antonblanchard's https://github.com/antonblanchard/ghdl-yosys-blink/blob/master/Makefile, when we collaborated for adding ECP5 support to ghdl/docker. Also because I'm the maintainer of ghdl/docker, I want to make it easier for users to consume those images without using makefiles (from Python).

From there on, the complex part starts: comparing and combining GHDLSynth.py, VUnit, tsfpga, cocotb and edalize. I believe those are the most popular solutions. All of them are written in Python, but each is different.

tsfpga

tsfpga is already a superset of VUnit, but focused on Vivado.

GHDLSynth.py could be merged/adapted into tsfpga, for supporting open source synthesis/P&R.

I already talked with tsfpga's maintainer (@LukasVik) about it and we agree. But other priorities have been arising these last months.

edalize

VUnit is already supported in edalize, but my opinion is that the implementation is partially flawed by design.

If I'm not mistaken, it's not possible to reuse existing run.py files. Sources need to be defined in edalize's format, and a subset of VUnit's features is exposed through hooks. At the same time, integration with Vivado is quite limited compared to tsfpga and I think that ghdl-yosys-plugin is not supported in edalize yet.

Hence, I'm not sure about the benefits of using VUnit in edalize as it is now. VUnit users will probably opt for tsfpga, because it allows to reuse run.py files and tweaks for simulation. OTOH, edalize users can already use GHDL or ModelSim without the VUnit bridge.

Overall, from VHDL's perspective, edalize is not attractive yet. That is, all the architecture needs to be checked for understanding whether it can fit non-trivial modern VHDL designs using GHDL + VUnit + OSVVM and targeting Vivado for synthesis.

See May 13, 2020 4:25 PM.

cocotb

The situation with cocotb is similar. I believe that VUnit should be used for managing tests and simulation sources, while cocotb (and other projects) would provide purpose-specific features. However, in @ktbarrett's proposal (https://github.com/ktbarrett/vunit-cocotb) VUnit is clueless about which tests exist, which passed, which failed, etc. In fact, the VHDL source does not contain any valid test that VUnit can find. As a result, most of VUnit's Python features cannot be used. Furthermore, log/report features are duplicated: VUnit generates reports independently from cocotb. See section "Reporting results" in VUnit/vunit#651. See also May 13, 2020 4:19 PM.

Hence, my priority would be integrating GHDLSynth.py into tsfpga and making cocotb a plugin for VUnit. That would provide a framework that VUnit and cocotb users could use for synthesizing either with Vivado (the most used tool) or with the open source toolchains (ghdl-yosys-plugin + Yosys + (nextpnr | VTR) + ...). Furthermore, it would allow Python-centric testing/verification workflows (cocotb) to coexist with VHDL-centric workflows (VUnit, OSVVM, UVVM), which is the most notable fragmentation ATM: https://larsasplund.github.io/github-facts/verification-practices.html.

rodrigomelo9 commented 3 years ago

My first thought about it was :flushed: (is a joke :stuck_out_tongue_closed_eyes: great explanations with a lot of resources)

I started PyFPGA as PyFPGA itself, almost a year ago, but I have been working on it since 2015 (started with ISE), I added Vivado, Quartus and Libero-SoC initial support at 2016, several changes in the middle, and new features last year as PyFPGA (Yosys synthesis for ISE and Vivado, GHDL synthesis in a branch). I will add support for icestorm/symbiflow cooming soon (I will have a new iCE40 board next week, I have an icestick but at work XD).

The main objective, is to deal with the vendors-tools (synthesis, P&R, bitgen and programming) in a easy way, from the command-line (https://gitlab.com/rodrigomelo9/pyfpga/-/tree/master/fpga/helpers) or programatically (Python). Actually, it supports ISE, Vivado, Quartus, Libero-SoC (partially), Yosys as synthesizer of ISE/Vivado and GHDL in a branch. Why only implementation? I already use cocotb, ghdl, iverilog and gtkwave, all of them capable of run from the cli.

Said that, I know almost nothing about Vunit. I mean, I read about it a few times, but I never used it. Let me know how can I help about the PyFPGA TODO.

I check edalize a time ago (see https://gitlab.com/rodrigomelo9/pyfpga/-/tree/edalize) but in my attempt, PyFPGA was a lot quicker (again, it could be unfair, because I am not an expert with edalize).

eine commented 3 years ago

My first thought about it was 😳 (is a joke 😝 great explanations with a lot of resources)

As you might imagine, my brain is burning as a result of all the info I made it remember in these last hours 🤣 . I beg your pardon as I might be too direct and/or sound crude.

I started PyFPGA as PyFPGA itself, almost a year ago, but I have been working on it since 2015 (started with ISE), I added Vivado, Quartus and Libero-SoC initial support at 2016, several changes in the middle, and new features last year as PyFPGA (Yosys synthesis for ISE and Vivado, GHDL synthesis in a branch). I will add support for icestorm/symbiflow cooming soon (I will have a new iCE40 board next week, I have an icestick but at work XD).

I guess that most of these projects started between 2013 and 2016. Some sooner, some later. Some were released in the begining, some took longer. I came a little later (2017), hence I decided I would not write a tool myself (although I was tempted). Instead, I spent a couple of years observing the community and the dynamics. Naturally, you were not in the radar when I created this repo, and I have not really done a further analysis since I knew about it.

That being said, my only concern about PyFPGA is the user base. As I did not really write my "own" tool, I have no problem to ditch GHDLSynth.py and adopt any existing project instead, as long as it satisfies the requirements. But my motivation for focusing on VUnit, cocotb and edalize first, is to tackle the largest user bases.

The main objective, is to deal with the vendors-tools (synthesis, P&R, bitgen and programming) in a easy way, from the command-line (https://gitlab.com/rodrigomelo9/pyfpga/-/tree/master/fpga/helpers) or programatically (Python). Actually, it supports ISE, Vivado, Quartus, Libero-SoC (partially), Yosys as synthesizer of ISE/Vivado and GHDL in a branch. Why only implementation? I already use cocotb, ghdl, iverilog and gtkwave, all of them capable of run from the cli.

This is where reality starts to be conflictive 😄. To me, using VUnit is a requirement:

However, VUnit is not a project management tool, and synthesis is out of scope. Hence, my understanding is that VUnit should be considered "The" Python test manager for HDL designs (not a Python verification framework). And we need to build "The" project manager for synthesis and/or formal verification on top of it.

NOTE: I am not ignoring SVUnit, but I hope that it can be combined with VUnit in the future. Anyway, they point is that SVUnit-VUnit are for simulation, and we need to handle synthesis (only).

From this point of view, my concern with edalize is it's trying to support a much wider scope than needed. A wider scope means less time for developing/maintaining and focusing on specific features. From a high-level abstraction, there are three groups of sources:

VUnit handles the two first groups. We need to handle the first and the last one. And we need to share the first group between VUnit/SVUnit and whatever we decide.

From this perspective, how do you see PyFPGA? Is there an explicit distinction between groups 1 and 3? Is it modular enough for removing the pieces that are redundant (if any)?

Please, bear in mind that the list of supported vendors (ISE, Vivado, Quartus, Libero-SoC) sounds really nice, and I'd love to have it integrated/combined anyhow. I'm just being inquisitive in order to wrap my head.

GHDL synthesis in a branch

Do you support using ghdl --synth as a "preprocessor" for Vivado? Do you use ghdl-yosys-plugin? Do you use ghdl-yosys-plugin along with Vivado? I'm really interested in knowing which of these alternatives you tried (regardless of the discussion/conversation above).

icestorm/symbiflow

See https://github.com/eine/vhdl-cfg/blob/master/GHDLSynth.py. I believe that's as simple as it can be, since it's not integrated in any larger framework.

The main objective, is to deal with the vendors-tools (synthesis, P&R, bitgen and programming)

Why only implementation? I already use cocotb, ghdl, iverilog and gtkwave, all of them capable of run from the cli.

This sounds awesome. I don't know why, I had understood that cocotb, GHDL, iverilog and gtkwave were also supported in PyFPGA. Then, I guess that you have separate makefiles and/or Python scripts for handling cocotb simulations which have nothing in common with PyFPGA?

Said that, I know almost nothing about Vunit. I mean, I read about it a few times, but I never used it. Let me know how can I help about the PyFPGA TODO.

On the one hand, you can take GHDLSynth as a reference for implementing it in PyFPGA on your own.

On the other hand, given your background and mine, I suggest the following:

For a very first contact with VUnit, see https://github.com/susanacanel/proyectos-vhdl/pull/4. You will find that most of the examples are variations of the same run.py file:

I check edalize a time ago (see https://gitlab.com/rodrigomelo9/pyfpga/-/tree/edalize) but in my attempt, PyFPGA was a lot quicker (again, it could be unfair, because I am not an expert with edalize).

This is something I dislike about my proposal above. edalize and fusesoc are left aside, and I really don't like that. However...

As discussed in January 30, 2020 4:44 PM, another relevant issue is that most of these projects use an imperative format for defining the sources. That is, there is no YAML/JSON schema where users can declare the sources of a project (groups 1, 2 and 3), and which is then used by several tools. This is true for VUnit and PoC, and for edalize and tsfpga too.

tsfpga is based on VUnit, and that allows to "reuse" some knowledge (see https://tsfpga.com/simulation.html and https://tsfpga.com/fpga_build.html#example-build-py). However, sources are defined imperatively too. There are some features for exporting those source to the JSON format expected by rust_hdl's vhdl_ls (see https://gitlab.com/tsfpga/tsfpga/-/blob/master/examples/simulate.py#L128), but not for reading them.

VUnit has a add_source_files_from_csv, but none of the existing integrations uses that approach.

In this regard, edalize, PoC and tsfgpa are currently mutually exclusive. I see that PyFPGA might be similar. What are your thoughts about it? Note that a possible solution to the dilemma is to define a YAML/JSON schema and very politely ask all the tools to support it. Patrick already said he would be willing to do it (for PoC), and Tristan (GHDL) is eager to having some standard that can be used instead of hdl-prj.json.

The main advantage of having an standard declarative format is that fragmentation is less critical, as users can have a common configuration point for multiple incompatible tools.

In fact, fusesoc is a declarative YAML format. See second large code block in https://fusesoc.readthedocs.io/en/latest/user/tutorials/1-getting_started.html#background and/or https://github.com/chipsalliance/Cores-SweRVolf/blob/master/swervolf.core. Hence, it might be sensible to use it as an starting point. However, I don't know whether any of the YAML semantic analysis and manipulation is reusable. I'm afraid it is tailored to the only available backend. In the docs, the distinction between fusesoc and edalize is blurry (see https://fusesoc.readthedocs.io/en/latest/ref/capi2.html#tools).

You might feel that this last paragraph contradicts all the previous explanations. And it certainly does XD. That's the beauty of open source. If you want to go this way, I'd suggest the following:

rodrigomelo9 commented 3 years ago

🤯🤯🤯 haha

I have to start with Vunit in my personal TODO list, so this point is a win-win.

To start with PyFPGA should be enough to read the small user guide and to see some examples (they are simples).

Is late here, let me take a look again tomorrow to answer something more complete. See you.

LukasVik commented 3 years ago

My name was tagged in this conversation, possibly by mistake in a copy-paste, but I will write some thoughts.

Hello @rodrigomelo9 I have seen your name around and looked a little into your PyFPGA project. I think you have a lot of good things going, but there is, as noted, a lot of overlap between our respective projects (mine being tsfpga: https://tsfpga.com/ https://gitlab.com/tsfpga/tsfpga ). I am not thrilled about the duplication of efforts in the open source FPGA community and would, like @eine, love to see more collaboration.

Unfortunately I have been busy lately, with the pandemic and running my own company. I have not taken the time to look at the "big picture" and the future/direction of tsfpga. There has actually been a lot of progress in project this year however, since I am able to do almost all the development on company time. But the work done has been mostly in the VHDL modules and the register generator, not in the core (python module/project system, vivado interface, i.e. the things that overlap with PyFPGA, edalize, etc.).

tsfpga has in the meantime been growing a bit in terms of adoption. I know at least three companies that use it (one being my own :smile:), and one more that is poised to start using it. These are "old school" FPGA companies that are not really present in the open source world, so tsfpga is still maintained solely by me and my colleague @LudvigVidlid .

I have a long-term ambition of perhaps migrating to use edalize as a backend, instead of using our own tcl generator (https://gitlab.com/tsfpga/tsfpga/-/blob/master/tsfpga/vivado/tcl.py). This would remove the duplication and overlap between tsfpga/edalize, as well as enable tsfpga to interface MANY more EDA tools than just Vivado. The downside of that is that edalize vivado interface seems in my opinion, which might be biased and is admittedly based only on a quick glance, to be not as high quality and well-tested as the tsfpga counterpart. On the other hand it is more adopted so definitely proven in use. It also lacks some of the features that I use, but I can of course add that.

Anyway, I will have to do some more research before I go down that route. tsfpga is written to support many vendors, despite only supporting vivado at the moment. The interface of the VivadoProject class can be used for any other vendor tool implementation. But I don't feel like writing my own implementation for things that already exist in other projects.

Another long-term ambition is to perhaps split the register generator to a separate project. Right now the tsfpga project is not very "focused", it has a lot of separate parts that are not actually tightly coupled. For example the register generator is completely disjoint from the rest of tsfpga. It is very possible that users out there want only the register generator but not tsfpga. The register code is mature and, at roughly 3000 lines of code, significant enough to split to a separate product.

BUT. Time is limited. I do not think I will be able to work on these things this year and a bit into 2021.

tsfpga is already a superset of VUnit

tsfpga is based on VUnit

Just a clarification: For simulation with VUnit, tsfpga automatically adds sources and testbenches if a recognized folder structure is used. It also enables local VUnit configuration setup without multiple run.py, using the module_*.py files. Apart from that, tsfpga is not based on VUnit.

rodrigomelo9 commented 3 years ago

Hi, I will try to answer only what needs an answer :P

From this point of view, my concern with edalize is it's trying to support a much wider scope than needed. A wider scope means less time for developing/maintaining and focusing on specific features. From a high-level abstraction, there are three groups of sources:

* (V)HDL sources of the design.
* (V)HDL and other (Python, shared libs, C...) sources for simulation (testbenches).
  * Can be multiple groups, should simulator-specific resources exist.
* (V)HDL and other (constraints files, device configuration...) sources for synthesis.
  * Can be multiple groups, should tool-specific resources exist.

VUnit handles the two first groups. We need to handle the first and the last one. And we need to share the first group between VUnit/SVUnit and whatever we decide.

From this perspective, how do you see PyFPGA? Is there an explicit distinction between groups 1 and 3? Is it modular enough for removing the pieces that are redundant (if any)?

PyFPGA uses groups 1 and 3 but without distinctions, using the add_files method (only Verilog Header files are using another method called add_include because some tools only need the path to where they are located).

GHDL synthesis in a branch

Do you support using ghdl --synth as a "preprocessor" for Vivado? Do you use ghdl-yosys-plugin? Do you use ghdl-yosys-plugin along with Vivado? I'm really interested in knowing which of these alternatives you tried (regardless of the discussion/conversation above).

Both of them, ghdl --synth only returns the synthesized VHDL and ghdl-yosys-plugin was integrated to the Yosys flow. I don't rememver why I never merged it XD (I was working on that at the beginning of the pandemic, and lot of work after that). I will work on that.

This sounds awesome. I don't know why, I had understood that cocotb, GHDL, iverilog and gtkwave were also supported in PyFPGA. Then, I guess that you have separate makefiles and/or Python scripts for handling cocotb simulations which have nothing in common with PyFPGA?

On the other hand, given your background and mine, I suggest the following:

  • First:
    • I will learn something about PyFPGA. At least, enough to hold a discussion with you from a user's perspective.
    • You will learn something about VUnit's Python and CLI interfaces (not VHDL libs). Again, at least enough to hold a discussion with me from a users's perspective.
  • Then:
    • I will look at tsfpga with a more critical eye (since I'm more familiar with VUnit).
    • You will look at ktbarrett's VUnit-cocotb integration with a more critical eye (since you are more familiar with cocotb).
  • Last, we'll share our thoughts with a better perspective. I believe we have two comparisons/integrations to do: VUnit-cocotb and PyFPGA-tsfpga. I'd say the PyFPGA-tsfpga is more interesting for both of us, but we might solve the other in the way.

Ok. I will start with Vunit (as I said, it was in my TODO list a long time :P). Also, it will be useful for https://github.com/rodrigomelo9/FOSS-for-digital-HW-design

About how to deal with files groups, PyFPGA don't deal with files handling. PyFPGA is mainly a Python class, which you can import with the rest of the packages that you want. Let me show you a simple Vivado example:

prj = Project('vivado')  # Here you are specifying the backend tool
prj.set_part('xc7z010-1-clg400')

prj.add_files('blinking.vhdl')
prj.add_files('zybo.xdc')  # PyFPGA internally identifies group 1 from group 3
prj.set_top('Blinking')  # [optional] It can be guessed (taken from the last group 1 file)

prj.generate()  # It generates the bitstream, but you can select performs only synthesis or synthesis+implementation instead

You can solve files handling with what you want and provides them to PyFPGA using add_files.

At the very beginning, I used a Makefile for ISE. Then, I create a multi-vendor Tcl file, which was managed by a Makefile and another Tcl file with options (a lot of files were involved). Here you can see my old and archived FPGA Helpers.

PyFPGA is based on a multi-vendor Tcl, where you change some parameters, using a Python class. You can see here the only Tcl behind PyFPGA, without Makefiles involved (bot mandatory, of course, you can use your own Makefiles to run a PyFPGA script).

Said that...

I really like the idea to have a unification of tools to deal with vendors-tools (using Tcl or what needed under the hood). And sound great to be part of something bigger (integration with Vunit, cocotb and whatever needed).

rodrigomelo9 commented 3 years ago

Hi @LukasVik, nice to meet you.

..but there is, as noted, a lot of overlap between our respective projects (mine being tsfpga: https://tsfpga.com/ https://gitlab.com/tsfpga/tsfpga ). I am not thrilled about the duplication of efforts in the open source FPGA community and would, like @eine, love to see more collaboration.

More than open for collaborations.

... But the work done has been mostly in the VHDL modules and the register generator, not in the core (python module/project system, vivado interface, i.e. the things that overlap with PyFPGA, edalize, etc.).

I think that the main core of a merge between tools such as tsfpga, edalize and PyFPGA, could be how to deal with the implementation (synthesis, P&R, bitgen).

tsfpga has in the meantime been growing a bit in terms of adoption. I know at least three companies that use it (one being my own smile), and one more that is poised to start using it. These are "old school" FPGA companies that are not really present in the open source world, so tsfpga is still maintained solely by me and my colleague @LudvigVidlid .

Yep, I understand. If I have more than a user, is because I have more than a computer :smile:

I have a long-term ambition of perhaps migrating to use edalize as a backend, instead of using our own tcl generator (https://gitlab.com/tsfpga/tsfpga/-/blob/master/tsfpga/vivado/tcl.py). This would remove the duplication and overlap between tsfpga/edalize, as well as enable tsfpga to interface MANY more EDA tools than just Vivado. The downside of that is that edalize vivado interface seems in my opinion, which might be biased and is admittedly based only on a quick glance, to be not as high quality and well-tested as the tsfpga counterpart. On the other hand it is more adopted so definitely proven in use. It also lacks some of the features that I use, but I can of course add that.

I thought about to use edalize as backend, and I did some tests. I haven't the time to be an expert, and what I tried takes longest times that PyFPGA, but probably it can be solved.

Anyway, I will have to do some more research before I go down that route. tsfpga is written to support many vendors, despite only supporting vivado at the moment. The interface of the VivadoProject class can be used for any other vendor tool implementation. But I don't feel like writing my own implementation for things that already exist in other projects.

As far I saw, Libero-SoC is not supported under edalize (I need to check, and maybe to add support let me know more about edalize).

Again, I am open to collaborations (I have not pleanty of time, but I love the idea of be part of an interesting FOSS project to supports FPGA development).

Regards

eine commented 3 years ago

As you might have noticed:

Hence, my proposal would be to add a subdir in each module for each of the tools. I'd start with 'demo', because it is simple and already proven in several boards. That is:

I would expect the same Vivado Block Design to be reused by either PyFPGA, tsfpga or fusesoc. Nonetheless, I think it's ok to have different TCL sources to start with.

Regarding CI, we cannot test vendor tools, but I'd strongly suggest to have all the open source workflows tested, as done with GHDLSynth.

@LukasVik,

Unfortunately I have been busy lately, with the pandemic and running my own company. I have not taken the time to look at the "big picture" and the future/direction of tsfpga.

I'd say we are just trying to understand the similarities and differences from a practical point of view. Understanding the big picture and reconsidering the future of the tools should come later.

tsfpga has in the meantime been growing a bit in terms of adoption. I know at least three companies that use it (one being my own 😄), and one more that is poised to start using it. These are "old school" FPGA companies that are not really present in the open source world, so tsfpga is still maintained solely by me and my colleague @LudvigVidlid .

This is why I think that the most "efficient" path going forward is:

fusesoc: declarative format for sources and parameters
|- PyFPGA: synthesis and P&R with multiple toolchains
  |- tsfpga: synthesis and P&R with Vivado
    |- VUnit: simulation
      |- cocotb: co-simulation

Ideally, either VUnit, tsfpga or PyFPGA would read fusesoc's YAML format (or a similar one). But I think it's ok to do the effort in a single place for now. Since PyFPGA is the project with the smallest user base and Rodrigo is the most proactive ATM, it feels sensible to prototype there (or here).

This would remove the duplication and overlap between tsfpga/edalize, as well as enable tsfpga to interface MANY more EDA tools than just Vivado. The downside of that is that edalize vivado interface seems in my opinion, which might be biased and is admittedly based only on a quick glance, to be not as high quality and well-tested as the tsfpga counterpart.

From a VHDL only perspective, I think that extending tsfpga through PyFPGA might provide a wide variety of EDA tools easier than integrating edalize.

tsfpga is written to support many vendors, despite only supporting vivado at the moment. The interface of the VivadoProject class can be used for any other vendor tool implementation. But I don't feel like writing my own implementation for things that already exist in other projects.

@rodrigomelo9, what do you think about a YosysProject class?

Another long-term ambition is to perhaps split the register generator to a separate project. Right now the tsfpga project is not very "focused", it has a lot of separate parts that are not actually tightly coupled. For example the register generator is completely disjoint from the rest of tsfpga. It is very possible that users out there want only the register generator but not tsfpga. The register code is mature and, at roughly 3000 lines of code, significant enough to split to a separate product.

What about moving those features to subdrectories (as we did in VUnit)? That allows to better show the modularity of the codebase, without the burden of maintaining a complete separate product. Sphinx can be used for organising the docs nicely.

I'm suggesting to do it for better understanding what's "the core" (the part we want to compare/integrate).

Just a clarification: For simulation with VUnit, tsfpga automatically adds sources and testbenches if a recognized folder structure is used. It also enables local VUnit configuration setup without multiple run.py, using the module_*.py files. Apart from that, tsfpga is not based on VUnit.

Is it possible to simulate with tools other than Vivado when using tsfpga? That is, the ones supported by VUnit (ModelSim/QuestaSim, Aldec, GHDL, etc.). That what I meant with "being based on VUnit".

@rodrigomelo9

PyFPGA uses groups 1 and 3 but without distinctions, using the add_files method (only Verilog Header files are using another method called add_include because some tools only need the path to where they are located).

I think it is important to semantically tell those groups (let's call them filesets as in fusesoc) apart. I believe we want to support the simulation fileset too, even though PyFPGA will not use it, but pass the content to tsfpga, VUnit and/or cocotb. Note that this might also be a frontend/overload of PyFPGA.

ghdl --synth only returns the synthesized VHDL

I think this is interesting as an optional preprocessor step to be executed before the regular Vivado build of VHDL sources. The use case is using Vivado for synthesis and P&R of sources using VHDL language features not yet supported by Xilinx.

Apart from that, Tristan considers it to be "test" for users to know whether their sources are valid, before running Yosys.

ghdl-yosys-plugin was integrated to the Yosys flow

I guess that you did not add Vivado as a Yosys backend yet. That is, you take Yosys + nextpnr as a single black box.

I started using GHDL and gtkwave in 2006, and iverilog in 2015, using Makefiles to deal with. I have no problems with Makefiles, I love Makefiles :-D I started using cocotb at the beginning of 2019. I use his Makefile approach. GHDL or iVerilog are used under the hood, and I add a gtkwave target in the Makefile.

But... do you want other users to love them? 🤣 A couple of days ago, Kaleb said: "Our surveys have concluded that users would be thrilled to never look at a makefile again".

So, I think that Makefiles are ok, and ghdl/ghdl, ghdl/ghdl-yosys-plugin, etc. will probably be based on Makefiles only for a long time. However, in the context of VUnit, tsfpga, PyFPGA, fusesoc, edalize, cocotb, etc. we should try to handle everything with a Python interface.

Ok. I will start with Vunit (as I said, it was in my TODO list a long time :P). Also, it will be useful for https://github.com/rodrigomelo9/FOSS-for-digital-HW-design

Apart from the User Guide, the PR in Susana's repo, and the examples in VUnit's repo, I added a testbench to this repo, which uses UART verification components. That's the most intuitive "real" example I could think. Note that two tests are defined, one for testing the counter, and another one for testing the UART loopback.

About how to deal with files groups, PyFPGA don't deal with files handling. PyFPGA is mainly a Python class, which you can import with the rest of the packages that you want. Let me show you a simple Vivado example:

You can solve files handling with what you want and provides them to PyFPGA using add_files.

Should we create that file handling class in this repo? My intuition is that we should not need to write it, but to reuse a subset of fusesoc's Python codebase. However, I don't know how reusable fusesoc's Python code is.

PyFPGA is based on a multi-vendor Tcl, where you change some parameters, using a Python class. You can see here the only Tcl behind PyFPGA, without Makefiles involved.

That's interesting! It feels familiar to https://github.com/OSVVM/OSVVM-Scripts, but OSVVM is for simulation only I think.

I really like the idea to have a unification of tools to deal with vendors-tools (using Tcl or what needed under the hood). And sound great to be part of something bigger (integration with Vunit, cocotb and whatever needed).

Do you feel like synthesising 'demo' with PyFPGA for all the tools/boards you support/have? Without changing anything in PyFPGA yet.

eine commented 3 years ago

I guess that you did not add Vivado as a Yosys backend yet. That is, you take Yosys + nextpnr as a single black box.

Replying to myself: see https://gitlab.com/rodrigomelo9/pyfpga/-/blob/master/doc/user_guide.md#basic-usage

The supported tool names are: ise, libero, quartus, vivado, yosys, yosys-ise and yosys-vivado.

eine commented 3 years ago

@Paebbels reminded me that pyIPCMI exists. Even though it's not in a good shape ATM, it already fulfills most of the requirements. See the list of supported toolchains: https://pyipcmi.readthedocs.io/en/latest/WhatIsIPCMI/SupportedToolChains.html. It supports management of regressions, report filtering, design compares, etc. Yet, it needs some updates for working out of the box. It was split from PoC, to be used independently, but there might still be partial dependencies on PoC.