[For readability, moderator comments have been removed, as well as minor questions for better understanding.]
Thank you. So it's not a talk exactly about GHDL, but more about how GHDL could be seen inside the open-source EDA ecosystem. So we have a lot of, many, talks about ecosystem today.
Okay, so quickly, it's, GHDL started as a simulator, it supports most of the standards, at least until 2008, there is a plan to support 2019, once 2008 is completely supported. It's a compiled simulator, so it generates at the end object code, and the structure of it is made to support multiple backends, so you can see GHDL as a GCC front-end, like C++, or Go front-end or whatever, Fortran, it doesn't, there is no intermediate generation of C code, it can be used with LLVM, and there is also an internal code generator named mcode which has the advantage of being very fast in generating, I would say, rather good object code. It's quite fast, at least to do the code generation, but the speed of simulation is not that fast, particularly if you use a lot of signals. I hope we have good messages, and I also hope we fix bugs quicker than the industry, not sure, but probably.
It's a full command-line tool, so there is no graphical user interface, and in order to debug your circuit, you can use GTKWave, which is also a famous waveform GUI, and to do that, you can either generate VCD output, which is slow and large, or we can also generate a specific format designed for GHDL and GTKWave, named .GHW file format, which is a little bit more compact and more powerful. Because it generates code, you can do some debug of your model using GDB, which is a little bit not completely nice. Because it can use GCC as a backend, you can do some coverage with Gcov, that's something also to be improved, and it supports most of the, at least of the open-source verification framework like UVM or OSVVM.
To open doors, what we'd like to have in future is to be able to do mixed-language simulation, so right now, if you want to simulate both Verilog and VHDL, or SystemVerilog designs, you cannot do that easily, and I think this is a real missing piece, at least for the VHDL world. Even for Verilog, there is no, I would say, easy-to-use IDE, that's also something that we need to be done to be able to easily debug, to easily view your output without something a little bit more interactive than GTKWave. In a different sector, I think there is also, I have never seen any plantation of tool to be able to design, to do design with graphical blocks, like it's possible with Vivado. Maybe Python is a better solution, maybe not always, I'm not sure, to be something to be discussed. There is also the topic of schematic viewer, so we want something to be better than GraphViz, something more interactive, more easy to reproduce, to investigate. I think this is also a missing piece in the open-source ecosystem. Okay, it's not very fun as a project, but that's something which could be also useful. And for the SystemVerilog landscape, I think there is no open-source simulator that can support UVM, which is a corral of verification, at least in the industry, but I have heard of some work in progress in this area.
There is this GHDL language server, which provides a language server for VHDL, so the integration with Emacs or VS Code or whatever, it allows to do, well, it's quite good to do navigation, and there is some support of reformatting and instantiation. I would say, okay, I am maybe not the only user, but one of the few users, and it quite improves the productivity, because when you start the simulation, there will be no syntax error, ideally it always works immediately.
Another thing I think would be nice to discuss, maybe for people outside of the FOSS EDA community, is why do we want to have open-source EDA tools. One of the issues, at least with simulator and maybe also with synthesizer, Xilinx or Altera/Intel, they offer at least free version for small FPGA, and they are very competitive for open-source tools, at least for the maker community, which is still a large community. Okay, so we don't want to target exactly this community, maybe it's a bit too hard initially. What we'd like maybe to target is also the industry. Okay, it's a bit like OpenROAD. Open-source tools allow industry to make some tries, some experiments with tools without investing a lot of money. The other possibility is this no-license restriction, so you can run many instances of any open-source tool at the same time, which allows you to do a lot of verification or a lot of state exploration.
Recently, well maybe a few years ago, I added synthesis support for GHDL. We have to understand that it only generates a netlist, which is completely un-optimized, and it generates either VHDL or Verilog netlist, and then it is integrated with Yosys in order to do optimization of this netlist. An interesting aspect of it is that there is support of PSL, both for simulation and for synthesis, which allows you to do some formal verification using SymbiYosys, which is quite interesting, except that PSL is not widely used compared to SystemVerilog assertions.
Okay, so again, we'd like also to support multi-language for synthesis. There is currently incomplete support with Yosys, because you can instantiate in VHDL a Verilog design, but there is limited support for parameters of generics. It would be also nice to be able to support cross-module probing for doing debugging, re-attack debugging. It might also be interesting to be able to do cross-language type definition, so you can more easily mix structure of records defined in one language with another language.
Finally, I have a rant about vendors. Maybe there are some here, I don't know. We all know that they are heavy users of open-source software. For example, many IDEs are based on Eclipse. There are users of LLVM or GCC. TCL, of course, is a de facto script for EDA. A lot of Linux is used everywhere. Unfortunately, they somewhat contribute back to this project, but it would be very nice if they were also more open in their format, in their bitstream. And for simulation, if they don't encrypt everything, because we don't have the key, so we are a little bit limited in what we can support with simulation for the FPGA.
At the end, we can say that there is a long story of open-source in the EDA. It starts back at least from SPICE, who everyone knows. It's still continuing in many, many directions, in many, many universities, and in many, many also communities outside universities. I think there are some still missing tools, like I said before. In particular, IDE, it would be something that would be... It's not a very fun project, but I think it's something that is also needed. And again, I think that still EDA vendors should be more open, if only they were. Thank you.
Q&A
-
So it seems this is the perfect talk for ending this workshop. Good messages and a lot of to-do's to attract young persons that want to get involved into open-source EDA development.
Thank you
-
So you mentioned with the mixed-language synthesis, have you looked into the Yosys ABC framework that lets it call a front-end with a set of parameters?
Yes, no. The point is, I not only want to do multi-language synthesis, I also want to support multi-language simulation. So in that case, Yosys is a bit out of this equation. And I also want to have the possibility of mixing types definitions in language, which also makes it a bit difficult with Yosys. So, yes, I am aware of that, but I don't plan to use it, at least in the long term.
-
First of all, thank you for GHDL. About five years ago, I suddenly stopped using VHDL and it kind of saved my life. Not having an open-source compiler was a death. And I want to say that I have used..., I'm one of the users of your Yosys GHDL plugin. I have successfully managed to simulate a large chunk of VHDL on the very latest step. I would say, not a small amount. Of course, the number of signals that you get are enormous sometimes, but to a certain extent, it's simulatable. And I'm just curious to know, because you listed so many things to do, I would like to hear more from you about your priorities on that. Because everything seems like this could be nice, it would be nice.
As a priority form?
-
... No, as like, what would you like to see be done first? And if so, I just have an idea what you think.
No, okay, what I plan to work on is mixed-language simulation. Okay, what I'd like to work on is mixed-language-simulation. What I'd like to see... I think I would be very happy to have a schematic viewer. Okay, there's a lot of research about...
-
...It feels manageable?
Yes. Because... Okay, if you do some design, and you need to understand why there is a problem with your design, you often need to use a schematic viewer. But that's one way to work.
-
Thank you, Tristan, for your talk. Thank you very much for your GHDL, and your involvement in the project. So I am from Sorbonne University, and we use a lot GHDL. So I may add an answer to the question, why I'm doing a FOSS tool. At university, it's really an advantage, a huge advantage to teach students with the FOSS tools, because we are able to explain the algorithms in depth. We are able to show them that they can interact with the tool, they can add something, they can improve, or degrade sometimes, but they can act on the tool, it's not a black box. And even for companies, EDA vendors, they like students who were taught with the FOSS EDA tools, because they learn the insight of the tools, not just clicking on buttons and things like that. So I think this is why EDA vendors also should become more open, because it's really an advantage for them to have a university teaching students with the FOSS EDA tools. And also, at university, sometimes we have advices to learn students with company tools, because in industry they will be using those tools, but as I said, knowing the insight and understanding the tool in depth is better than just knowing the graphical interface. Also, at university we have licenses at a good price for the EDA company tools, but we don't have access to hotlines. With the FOSS EDA tools, the students can interact on the web, on social networks, and interact with other designers or designers of tools. It changes ideas. And everyone is looking for students in VLSI design in the EDA tools. Everyone wants to hire more people. So if we don't give students exciting things to do, they will go to other things. I don't want to mention them, but maybe we can discuss that later.
Just to comment a little bit, at least on the support part, I think it's true that maybe you can find a lot of information about open-source tools on the web and a lot of discussion. It's also always surprising to me that, if there is something I can quickly fix, I can do it in a few days, no problem. And often people are very surprised of the speed compared to the industry. No comment.
-
It's a great project. Thank you. I'm so happy to be here. So I'm the author of Hog. And we plan to support GHW. And especially the thing you said about using [?] here... I'm concerned now it's a big problem, because you run simulation and then its on to the licenses plate. But what's the current plan to support IPs? Xilinx IPs, for instance.
No, there is no plan. I think during the ISE period, most of the IPs were completely open when it was VHDL. Most of the time it was both VHDL and Verilog. And GHDL could handle them without any issue. And nowadays with Vivado, it's more and more encrypted. What can we do except... If we want to stay legal, what can we do? I don't have any...
-
There is no channel of communication open between you and Xilinx? They don't care at all?
No, no, you know, Xilinx provide their own simulator, so I don't see any way I could try to convince them to open a bit more.
-
...we work with Questa, so there must be an agreement...
Yeah, sure, they have agreements. They have agreements with Questa, with the vendors, but not with any open source tool...
-
So it's more just about the Xilinx thing? I think it is something that if people have contacts at Xilinx, then it's definitely worth pushing on, because we did previously get them to relicense the unencrypted primitives, or accept the unencrypted primitives, as I think it was Apache2, instead of a commercial license. So it is possible to get them to budge on things, it just requires more steps. So it's probably not something that should be written off altogether, it won't happen overnight. But yeah, if people know about that at Xilinx, then yeah.
Well, we could just hope for the best...
[Audience member A:] Great that you said that, because I was going to comment on the code, I'm sure it would be nice. There is hope for the best, but find it for the worst. And there's also the serenity prayer, which says, "God grant you the wisdom to change the things that you can, accept what you cannot change, and the wisdom to know the difference." And there's also, what is the best alternative in any negotiation or discussion? If there is no compelling reason for a highly consolidated duopoly or triopoly to link or to change things, it won't change. We are in a very mature semiconductor industry. So I think this is why, whether it's in Antonino's special session at ICCAD about the next open and proprietary EDA Commons, why do we have these sorts of discussions? It's because really the situation is quite static, and the only community that can move or hopefully will be willing to move is the open-source EDA community. It's not going to be incumbents. So I just wanted to highlight that. I mean, we can all be hopeful. But the reality is we don't have time in affluence. We don't have people. So what are we going to do differently? For example, will people converge on design drivers or benchmarks or interoperability or shared engineering? I mean, is there any such outcome of this workshop, of this division? I mean, I understand we all learn a lot about each other and what's open, but concretely, between this year and next year, what structurally will change in the FOSS EDA community, would be my question.
[...]
[A:] No response? Nobody's going to raise their hand and say, "I want to donate this!" or "I commit to do this!". I'm sorry.
[Speaker:] You want an immediate answer? You'd like to have an immediate answer.
[A:] Yeah. Because that's what we do. I mean, somebody says, "I'm going to open-source this [?]", or "I'm going to develop this vertical benchmark". "I'm going to provide a test bench for this so we can do calibrated power calculation and dynamic power calculation", vectorless, vector. I mean, there's so much stuff. SI, CCS. I mean, in the ASIC world, of course. But it's a huge list. And who's going to help drive this or create the building block? You kind of stay under the lamppost if you want to look under the lamppost, but the light is better. But there's a lot of other parts that are not very delineated that still need to be handled. Definitely in silence. I understand. Sorry.
[Audience member B:] Everybody was expecting you to do these.
[A:] We'll try with a very finite resource.
[B:] I know.
[A:] Having tried this, just wondering, can we put more wood behind fewer arrows? It doesn't have to be... It could be a four-bit [?]. It could be anything.
[Audience member C:] I appreciate the more wood behind fewer arrows. I mentioned excitement earlier. One mechanism is to try to attract more young people, undergraduates and classes and competition and stuff. Try to build excitement, and that's what will get them all working. And the fewer arrows, I guess what I would say is that it's very hard to discourage people from working on their pet projects. But encouraging more interoperability so that you can share code, even if you're not sharing the name of the top-level organization, there are more libraries that can be intertwined, more file formats that can be shared, ways to interoperate so that the community can mix and match according to their needs, and the winners and losers can perhaps be made more obvious.
[Audience member D:] So I think one aspect is what are you willing to contribute, and another aspect is what would you like. And I think in terms of what we would contribute, by we I mean the community, I don't have any very specific other than discontinuous improvement of the open-source tool that's available already out there. In terms of what I want, actually I do have some very specific needs, and I don't know how to get it. Because I use FPGA on a daily basis, and there are two top-level main points for me, neither of which are directly addressed by many of the research models. The first main point is not about performance at all. It's about the design cycle speed. The fact that you have to wait for so long every time you make the slightest change to your design. Now, I understand that it's a difficult problem in general, but I have a lot of structured information I have available to me at the source code that is being completely thrown away in trying to re-synthesize and re-PNR from scratch every now and then. I have modular structure, et cetera, et cetera, where it seems to me that it ought to be feasible to do an incremental change in one part of the FPGA without touching the rest of the FPGA, and hopefully the design cycle will be able to speed up there. So that's something I really would like to see in anybody's tools to be able to iterate much faster. And it's not just me. I think there are thousands of FPGA programmers, and all their man-hours are being wasted on the same problem, on this problem. And it's not about best block rate, it's not about best area, et cetera. It's outside. I think best block rate and best area is the light under the lamppost, and the problem I think is a little bit outside the lamppost. The second problem I have is a little more mundane, probably easier to solve. It's simply a naming problem, which is that the timing reports that I get from FPGA tools make it difficult for me to relate it back to where the issue is in the source code. So that's a much smaller, but more mundane, but also equally useful problem. And I understand why the timing is difficult. Maybe because I'm not a user. It's because the names chosen on the path are often on FPGA-fabric terminology. This thing or that LUT or, you know, et cetera, on which I have no interest. What I want to know is my RTL variable? And sometimes the naming, because of the chance choice of choosing one name, which might connect to many different points in the name, it's the wrong name for the path that I want. So it's a little bit of a mundane problem. That's one thing on my end. Those are the two big things on my end.
[A:] Just a comment. You know, what Intel calls interactive RTL, it's a problem for ASIC folks as well, where they want a 15-hour SPNR to be covered for that turbulence. And this has been a challenge from almost every company on the planet, in the ASIC world as well. And so, you know, OpenROAD, for example, has RDP. And then after, it has incremental global placement, where you swap in different sub-networks and fix up what you had before. It's far from where it was originally. Yeah, we understand this is a huge problem. And maybe, you know, since there's electrostatic placers, you know, for the PPA tool chain, the same code could be used. And about naming, in, again, the ASIC world, the report formats and the names are actually copyrighted. And so there is a constructive Tower of Babel in the commercial PPA world. If you look at, I think, our announcement in 2019, we actually published state naming conventions in the world that were directly given to us by a company that had survived a lawsuit from a bigger EDA company, and they had to put up their names. And so, even by construction, you have to adopt safe names and safe timing reports that actually match any existing timing report in your own time loop. Otherwise, you get sued. So we have this kind of problem, and again, that's where one road instead of five road hits, or one, you know, this is how we report a timing hop, with up arrows or down arrows or R's and F's, or this comment or that comment. All we need is one common way of doing it. And that will help a lot.