Project Systems Engineering #469
Comments
|
First what comes into my mind is
|
|
My personal priority list is this:
|
|
@andreygursky @Paebbels Thank you for getting back to me.
To provide some context for my class project I'm not only looking at the technological aspects of GHDL but the sociological aspects as well. The outline for my project report is this:
Some questions that I will be answering is: based on the issues and needs of this project, which ones will provide the most benefit for stakeholders? What is the minimum amount of effort needed by project members to bring GHDL to a point where digital designers and companies would use it instead of proprietary simulation tools? How can the goals be realized in a finite amount of time? I'm sure you all have run across Philippe Faes's article Why is GHDL (currently) not good enough?. Faes declared that there aren't enough contributions being made to GHDL. Has this changed in the last seven years? Are the amount of contributions by team members adequate to satisfy GHDLs open issues in perhaps the next 5 years? 2 years? Have there been efforts made by anyone to recruit more team members? I ask these questions because I'd like to use GHDL instead of Modelsim professionally and I'd like to describe a path to accomplishing this. I believe that part of a plan to get GHDL to be competitive with commercial tools will involve recruiting more people to make contributions and I plan on applying concepts from the book Peopleware to make recommendations towards this end. |
|
ghdl has changed MASSIVELY in seven years, to the point where I doubt Philippe Faes would maintain his criticisms today. It IS still written in Ada (not ADA) but despite his talking that down, the inside story is that Ada is ghdl's secret weapon - it would be practically mpossible for almost any size of team to match ghdl's quality in any other language. (I'll expand on this : a few years ago I had some involvement in restarting ghdl after looking around for a decent sized open-source project to help me learn Ada : most of the problems I had were in the vanishingly small C interface between it and gcc) As an alternative to UVVM (which I have virtually no experience with, but I agree would be nice for ghdl to fully support) I suggest you might like to look at OSVVM (www.osvvm.org) which does support ghdl and the VUnit testing framework. |
Currently, GHDL has only a VPI (Verilog Programming Interface). This is also used to interface with Cocotb. Consider VPI as a lightweight version of VHPI. It would be good to have a full VHPI interface in GHDL at some point in time. I believe even a VPI equivalent VHPI interface would be a good start, because all interfacing mechanisms and accessing internal data of the simulation model already exists. @JimLewis and @PLC2 are working on OSVVM based Verification IPs (VIPs) that are comparable to UVVM. |
|
I've summarized the wants/needs of this project from the above posts:
Broadly speaking, how much effort would it take to implement these features? Are we talking years? Would there be significant refactoring or would the project need to be re-architected? Also, as a bit more of a touchy feely question: why are all of you working on GHDL? @Paebbels mentioned that he would like to use it as a teaching tool. What are you hoping to get out of it? |
|
GHDL is the only chance to have VHDL2008 features available in small companies which have not enough FPGA business to buy commercial simulator. In general I could live without VHDL2008 for RTL (as ISE for spartan Synth doesn't support it) but for simulation it let me use for example VUnit. I can't even imagine how I could work without it previously... I miss a bit full support for UVVM, but I'm glad to hear that there are plans to introduce VIPs to OSVVM. I might even find some time to develop Wishbone BFM if it won't be added at the beginning. |
|
#453 ghdl-llvm crash when compiling uvvm |
|
@Paebbels I have five questions: What would VHPI add over VPI? Is VHDL-2018 an IEEE standard? I haven't found a reference to it yet. Is the Python interface that @tgingold is working on intended to replace Cocotb? @Brian-Drummond, I have one question. I see that OSVVM is a collection of VHDL files to implement an architecture to support constrained random variable testing (like UVVM). I believe that OSVVM and UVVM are both implementations of constrained random variable testing. Is this correct? Do you think OSVVM has advantages over UVVM? @slaweksiluk What are VIPs? Thank you all. |
|
I have submitted the GHDL Upgrade Study to my systems engineering professor. You all will have a chance to see it soon. When it is graded I will post it on this discussion. |
|
Great! Looking forward to it.
|
|
@eggsactly answer to your questions:
|
|
Here is the final report for my Systems Engineering class for GHDL. I would like to thank you all for your help in answering my questions so that I could put this report together. |
|
Thank you.
There are several interesting points, in particular the ordered list of features.
… Le 16 déc. 2017 à 22:59, Garrett Weaver ***@***.***> a écrit :
Here is the final report for my Systems Engineering class for GHDL.
final-deliverable.pdf
I would like to thank you all for your help in answering my questions so that I could put this report together.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@eggsactly
|
|
@eggsactly thank you for choosing GHDL as your class project. It is interesting to see the project analyzed from different points of view, and this helped us make this exercise. Related to @Paebbels' comment, I also felt the report to be quite informal in the sense that many assumptions seem to be done, and the overall feel is that we are dealing with a very personal and somehow biased interpretation of the context. I.e., it is difficult to evaluate if the analysis lead to the conclusion, or if it was made up to make it fit. However, it is not our duty to evaluate your work, but your professors's. This is specially so because it is directly related to the time you had to elaborate it, your initial skills, and how you applied the system engineering concepts. Therefore, I take comments by @Paebbels as suggestions to enhance the work, in order to use it as a 'report' and not a 'report for a class project'. In this sense, what attracted my attention most was the introduction:
On the one hand, both GCC and LLVM can be used as backends for GHDL, and GDB can be used to debug VHDL programs: http://ghdl.readthedocs.io/en/latest/using/Simulation.html#gnu-debugger-gdb
On the other hand, GHDL is not a synthesis tool, but a simulator, as explained in http://ghdl.readthedocs.io/en/latest/about.html#what-is-vhdl .
Why mention synthesis in the paragraph above if the report is about simulation and there is not any other reference to synthesis at all? I'd expect a simple explanation in-between, such as synthesis tools for commercially available devices are platform-specific and content protected by copyrights and patents is needed to implement them. However, anyone can implemented a VHDL simulator. Because detecting issues quick and early in the design process can reduce the overall duration of a project, this report is focused on a free, full featured digital design simulation and verification tool.... Otherwise, I'd expect free tools related to synthesis to be referenced (e.g. see page 9 in Open source tools for FPGA development). Indeed, stating the difference between simulation and synthesis is important because in 1.2 you wrote VHDL simulators allow designers to model a digital circuit at the Register Transfer Level (RTL) with the As you see, it is very important to properly set the context in the introduction, in order to focus the reader on what you want to analyze, and to ensure that expectations are fulfilled when the report is read. Yet, I think that some parts of the report might be added to the docs. For example, Who uses GHDL? can be extended to include 'who might use GHDL', i.e., the stakeholders. @eggsactly are you willing to contribute with this or do you consider your work to be finished? Also, the 'Design Team' section is very interesting, as it reinforces some of the enhancements we are already working on. |
|
@Paebbels and @1138-4eb Thank you for reading my report and thank you for your feedback. In retrospect I should have done more research on the claims I made. I appreciate that you provided much more detailed feedback than my professor and TAs could (in a class of several dozen students, all with very different projects). @1138-4eb First to answer your question regarding the section Who uses GHDL I would like to contribute. I consider my work "done" only because I turned in the assignment. I certainly expect that revisions are necessary for work intended for the general public. @Paebbels, regarding your comments (paraphrasing)
I definitely agree, you have to flip between pages to understand it. Not a fun experience. If I were to write this again I would find a way to put the requirement and stakeholder text in the table (preferably while keeping the LaTeX markup DRY) and add check marks and row headings.
In researching VHDL simulators I did stumble across Active-HDL. I choose to look at GHDL because it has better cross platform support (I got it to run on Debian). If I were to write the report again I would have mentioned Active-HDL, Riviera-PRO and QuestaSim in section 4.
I ran a little system verilog test with iverilog and I can confirm that you're right. Version 10.1 of the tool does not support sv. I thought it did because I read on Wikipedia that edaplayground uses iverilog on the back-end. I suppose doulos is doing something else under the hood with that tool.
I used informal English in the heading text because Peopleware (one of our course text books) had similar headings, although it was certainly not a formally written book. Regardless I was using two different writing styles, it would have been more professional if I wrote the report more formally.
Thanks for identifying some of my unsupported statements. Of course I had no reference stating what languages are mostly used by which industries in different parts of the world. The notion of VHDL and Verilog mostly being used is knowledge within my development community and I did not seek out what other groups use. I'm glad you're working on the IEEE issue. I would like to be able to run
True, but I'm unsure that it's necessary to cite every time. I've been told by English teachers (for other classes) that you only need to cite an author the first time you quote them, all other times after the first quote the citation is implied. This was in the context of MLA citations though. I used LaTeXs default citation format, which may follow different rules. It may have been better to play it safe and just cite every quote. @1138-4eb I address your comments below:
This is a valid critique. What motivated me to do a report on GHDL was that I was using it to develop a Coarse Grained Reconfigurable Array for my original project for the class (which was overkill for the context of the assignment). Although I liked GHDL more than other simulators I looked at for a simulation tool, GHDL did not meet all my expectations. I realized that it would be very difficult for me to continue my original project. So I changed my project two weeks before the deadline to a study of GHDL. Although this afforded me a higher probability of meeting my deadline it also guaranteed that I would write the report in only one frame of mind. The feel of the paper was motivated by personal frustration. Ultimately I choose to do my report on GHDL because I think that it's a great project, a lot of things in it do work really well and it shows a tremendous level of effort. If I had changed course sooner I would have had more time to elaborate on my assumptions and develop a more nuanced and objective perspective. Granted GHDL can use GCC or LLVM as the backend (which is really cool). It doesn't feel like digital designers have access to a full suite of free tools like software developers. As a software developer I can develop a useful and complex tool without touching anything proprietary, I can't do that as a digital designer. It would have been better if I had used a different reasoning for the motivation of the project. Lastly if I were to write the report again I would just take out references to synthesis, it's more padding than anything else (even though I had no page count requirement) and it doesn't contribute any valuable information to GHDL. |
It appears cocotb has come back from the dead. Its project page seems very much alive: https://github.com/cocotb/cocotb . I was able to run a ghdl+cocotb sim with waves. I agree, I like the idea of a Python interface to GHDL.
This may be a reference to iverilog+eUVM (embedded UVM). eUVM uses VPI so it may be possible to run GHDL+eUVM. http://uvm.io/docs/integration/icarus-verilog/ |
Yes. After being dead for 1-2 years, it was brought back to live by @cmarqu, @eric-wieser, @themperek, @imphil and others. @ktbarrett seems to be the most active code contributor lately. The comment by Paebbels was written precisely in Dec 2017, when it was effectively dead: cocotb/cocotb#513.
cocotb works acceptably, it is a very interesting approach and it allows verification for non-HDL developers. However, it is not a Python interface to GHDL. It is a Python interface to VPI and/or VHPI, and because GHDL's GRT (runtime) supports VPI, cocotb can interface simulation binaries/models generated GHDL. GHDL's GRT supports a custom interface too, which is named VHPIDIRECT (ghdl.github.io/ghdl-cosim). VHPIDIRECT is a direct interface, similar to SystemVerilog's Direct Programming Interface (DPI), which allows tightly coupled co-simulation. GHDL's VHPIDIRECT allows VHDL to execute arbitrary Python snippets/callbacks, and it should allow Python to execute VHDL functions/procedures too. All the interfacing from Python is done with Overall, with VPI/VHPI you get an API that allows you not to write a single line of VHDL. Conversely, with VHPIDIRECT the logic can be split between VHDL (testbench) and Python sources, and you build your custom API. Anyway, both solutions are (will be) feature-equivalent, allthough both are incomplete yet. For example, ATM cocotb does not support records or arrays (see #1249), but with VHPIDIRECT you can pass multidimensional arrays (matrices, cubes... see https://ghdl.github.io/ghdl-cosim/vhpidirect/examples/arrays.html); or cocotb supports accessing elements through hierarchical names, while that VHDL 2008 feature is not implemented yet (see #548). The are some proposals to add a Direct Programming Interface to the next VHDL standard. One of them is about completing and making GHDL's VHPIDIRECT a standard: https://github.com/umarcor/ghdl-cosim/blob/vhdl202x-lcd-dpi/vhdl202x-lcs-dpi/main.md
Yes, it should be possible to do mixed-language (VHDL + Verilog) co-simulation using two simulators that support VPI (e.g. GHDL and iverilog). However, AFAIK, that has not been achieved yet. My guess is that the idea behind VPI is that the simulator handles execution time and specific callbacks are called after certain events. I.e., the external interface (Python) is not expected to drive the clock(s). Hence, with two simulators, there are two independent domains being executed independently and generating unrelated callbacks. On the other hand, GRT's VHPIDIRECT is a lower level interface that allows handling time from the external interface, similar to how it is done with Verilator models. This is done in https://github.com/ghdl/ghdl-cosim/tree/master/systemc to co-simulate VHDL and SystemC. Recently, @ozbenh reported successfully co-simulating VHDL (VHPIDIRECT) and Verilog (Verilator) using this approach (see #1335). How to do it has not been documented yet: ghdl/ghdl-cosim#14. Furthermore, VHPIDIRECT has been shown to be more effective and compact (compared to cocotb) for mixed-signal co-simulation using Xyce and GHDL (see #1052). These and other co-simulation use cases are listed in https://github.com/umarcor/ghdl-cosim/blob/vhdl202x-lcd-dpi/vhdl202x-lcs-dpi/main.md#use-cases. https://ghdl.github.io/ghdl-cosim/vhpidirect/examples/index.html contains ~20 examples for you to test and adapt to your needs. Note there is a "problem" with open source Verilog simulators. Verilator supports the synthesizable subset of Verilog, only. Hence, it cannot be used for co-simulating arbitrary Verilog code. At the same time, iverilog accepts a wider subset of the language, but it does not provide a "direct" interface/model; thus VPI plumbing is required. The support for SystemVerilog is significantly worse. That's why the most surprising part of your comment/ref is: did Accellera ditch SystemVerilog? Is E-UVM some independent rewrite? How is compatibility between UVM and E-UVM guaranteed? It feels to me that E-UVM is unrelated to UVM (same as UVVM or uvm-python), but Coverify Systems Technology is offering a new co-simulation/verification framework that is distributed as a shared (C/C++) library:
This is very interesting, indeed. E-UVM seems to be "just" a shared library that you can load and call from the simulation. Hence, it should be fully compatible with VHPIDIRECT. Moreover, I believe it should be easier to integrate it with VHPIDIRECT, rather than using VPI (as happened with Xyce). However, the issue of not being able to simulate "standard" UVM code (SystemVerilog) with open source tools remains... |
I've done some mixed simulation with MyHDL as master driving GHDL or iverilog through VPI, but the master testbench (in this case MyHDL) needs to drive the clocks and I/O stimulation in order to run efficiently. Any sorts of callbacks across different simulation contexts (multiple threads) can turn out problematic and in some cases even slow down your simulation. So in order to avoid that you'd have to pack your V* model into a component that works like hardware with interfaces. If that should be driving something external like a master, I'd typically go 'asynchronous' using VHPIDIRECT (ghdlex) to get maximum thread performance. |
I'm working on a class project to apply systems engineering concepts to a real life project. I would like to work on GHDL because I did computer engineering for undergrad and I've done some experimentation with GHDL. I like what I've seen with GHDL/GTKWave, but in my opinion it's not quite at the level of commercial tools like Modelsim (but it's really close). I would like to see GHDL be competitive with commercial tools and the focus of my project will be how this can be achomplished.
I'm submitting this "issue" because I'd like the output of my project to be useful to the GHDL project. I'd like to ask questions about how well you feel GHDL is progressing, what you are trying to achieve with the project and what you perceive your needs to be so that I can focus my efforts.
Lastly I've submitted this "issue" as a last resort to reach out to this project. I would have submitted this message on the mailing list but I see GNA has been down for nearly a year. I also sent a similar message directly to Tristan yesterday, but I fear it was intercepted by a spam filter.
The text was updated successfully, but these errors were encountered: