GHDL: a complete VHDL parser #111
Comments
|
On 02/07/16 07:52, 1138-4EB wrote:
Wow, a lot of references. I haven't yet read all these pages, but I can
Yes, it is suitable. GHDL is able to parse and analyze vhdl sources and
No. The AST representation (documented in iirs.ads) could be read from
Far from being complete. VHPI is only supported for the simulation
It is already possible to display the hierarchy using the --disp-tree I will comment on the first part of your message later. Tristan. |
|
On 02/07/16 07:52, 1138-4EB wrote:
In fact you want more than a vhdl parser: you also want a vhdl GHDL has all these data, at least internally. The options --disp-tree Generating a dot/graphviz connection net shouldn't be very difficult. Tristan. |
|
I close this issue as this was just a question. Tristan. |
|
Nice idea, i had something similar in mind. Perhaps you can leave your e-mail address to stay in touch? So i will comment with what i know, point by point.
I'm doing the parser and hopefully later the elaborator. I'm building this in haskell and the progress is slow but steady. I haven't started on the problem of Planarization so this area is still wide open. I decided to start with parsing because this would already be useful, and other tools build on top of it. For visualization javascript would be preferred because it plays well with html documents, publication on the web and atom editor. I was planning to leverage ghdl to provide values of signals at a point in time. Or even to solve small snippets of logic. For example, given the following code: variable A, B, C, D : boolean;
if notA && (B or C) then
D := '1';
else
D := '0';
end if;
Too bad i was unable to install ghdl, now i'm looking to interface with modelsim, but this is also not an easy thing to do. Have you got ghdl working?
I'm not sure if a synthesis step would actually make it "more complete" ... after synthesis a lot of information is actually gone. |
|
On 21/07/16 17:19, flip111 wrote: [...]
Can you clarify why you were unable to install ghdl ? We do provide Tristan. |
|
On 22/07/16 19:55, flip111 wrote:
Ah, ok I remember. But you should try the llvm or mcode backend instead |
I am trying to make co-simulation between CλaSH and Verilog/VHDL; CλaSH is actually just Haskell code... Co-simulation with Icarus-Verilog and Modelsim works currently. Simulation can be done with source-files or with quasiquoters, in which the module is used as string (written to file) currently. A future idea is to use a parser within Haskell to for example splice Haskell values in the DSL. Will your Haskell parser be freely available? If yes, can your parser be used in this context? After I installed Icarus Verilog on a clean Ubuntu 16.04, I installed GHDL with the following commands: sudo apt-get install zlib1g-dev --# GNAT GPL 2016 --# GHDL |
|
@jgjverheij you can not simulate CλaSH code directly as far as i know. CλaSH code compiles to vhdl or verilog. If you wanted to simulate CλaSH code with existing designs in RTL then you can generate RTL code first and just port map it like usual. Thanks for the installation instructions ... it installed. While elaborating it seems a file was not installed properly. This |
|
@flip111 currently it is correct that is not possible to simulate CλaSH code with existing designs in RTL. That is why I am implementing co-simulation to make this possible. Hereby a small Verilog example: Which gives the following result: To splice Haskell (CλaSH) values into this module, for example to create this: ...a parser has to be created (in this case Verilog). When you said you are building a VHDL parser in Haskell, it got my attention, because that is something I can use to give more possibilities within the co-simulation. |
|
@jgjverheij Sorry for not gettin back to this earlier. Congratz on getting your verilog/clash interface repo up! I haven't checked tried to run it though as i am just interested in VHDL for the moment.
Both these sentences i don't understand what you're getting at. Unfortunately work on the VHDL parser is stalled because i'm lacking the appropriate haskell skills to finish it (after already many attempts). The state of it is that i have ~4500 lines of code ... all the rules are implemented (but not working) in VHDL 1993. Got basic machinery up for testing and pretty printing. For the moment the following rules are working:
That's it ... the top rule
|
|
Hello, |
|
As far as I know, there is no free working VHDL-2008 grammar available on the internet. The grammar you are pointing to is GPL 3.0 license so it prohibits a lot of use cases... It also contains no special case handling rules for all the corner cases in the VHDL language. As far as I know, the ANTLR4 grammar needs a lot of additional manual handling to get it working with VHDL. That's why I started my own Python implementation of a special kind of VHDL parser: pyVHDLParser. |
|
@Paebbels i'm still looking for a library that can display entities and connections visually, do you know a good one? |
|
@flip111 |
|
@Paebbels i mean a digital schematic as can be generated by for example Vivado. It would be nice to use parts of the schematic as images in documentation. |
|
@flip111 |
|
@Nic30 whao that's very cool you found a good algorithm. I searched for this for a long time. So your solution is al javascript based with D3.js? That would be perfect. |
|
Yes, D3.js is used for graph rendering, Angular is used for for data handling and flask is used as python server. |
|
@Nic30 , related to the topic, how do you get the structure of the modules? Do you use any parser? |
|
@1138-4eb Nic30 his software seems to be located here https://github.com/Nic30/hdlConvertor I also want to mention https://github.com/Paebbels/pyVHDLParser which seems to be a nice parser which also supports VHDL 2008 Also found this https://kevinpt.github.io/hdlparse/ which is a newer library (between 2 and 7 months old) to generate documentation. |
|
As @flip111 wrote. Also I am searching for cooperation. I am offering my help on similar project or anyone can help me. I am interested in everything which is related to HW especially HLS. |
|
@Nic30 I have a meaningful update to this thread in the oven. It is focused on trying to come up with a collaboration scheme so that we can try to integrate the pieces and proofs of concept we have been developing independently. As you can see, I already edited the first comment, to include explicit references to pyVHDLParser (which I knew about, but I had not given it the relevance I feel it has) and to your solution. Just to be clear, I do think that ANTLR4 is a dead path for the matter at hand, in the sense that at some point (which can be quite late) it will be harder to 'hack' ANTLR, instead of going with a different concept (say pyVHDLParse and/or GHDL). However, don't take me wrong, I find the frontend part of your project very interesting and inspiring. Indeed, I am ok with using ANTLR as a quick input source to the frontend, as long as we use some intermediate format between the parser and the visualizer, which let's us swap either of them. NOTE: the content below might be copied and/or moved to a different thread soon. See note at the end. I somehow drafted that (JSON) format here which is an extended (and IMHO improved) version of the format used in icestudio, by taking ideas which are useful for a complete design flow (from edition, to simulation, synthesis, P&R and programming/configuration). In also considers the possibility to define data in a single or multiple files (this part is also above, but it is still in spanish). However, there might already exist a format which can be directly used. I'd like to hear about alternatives. My proposal is to use this thread to discuss parsing. Since this is the repo of GHDL, I would focus on how to use/enhance Then, I would open a different issue to discuss data requirements to build the visualization libraries/tools. We would discuss details about the intermediate format there, and set the minimum requirements which should be met by any parser in order to be usable (say GHDL, pyVHDLParser, ANTLR4). Note that the inputs can be not only parsers, but also 'documentation tools', such as Doxygen or VHDLDocL. Last, I'd open a thread to talk about technical details to build the visualization libraries/tools. I like your approach using
When i first found mxgraph a couple of years ago, it was not open source, but a paid library. Then, although it seemed promising, I discarded it. Moreover, I was convinced that a tool for hardware design had to be written in compiled languages (say Ada, C, C++, golang) because of performance. And this is/was Java and JavaScript. Well, both issues have changed now:
And... well... this is open source, free (as in free beer), and requires only 2.34MB. That's just one among multiple examples. The most exciting to me is wires. Note that adding a golang backend (10-20MB) and GHDL, we are talking about <30MB. Damn cool. @Nic30 are you willing to consider the possibility to replace D3.js with mxgraph? I.e., use tha same ANTLR4 parser and layout algorithm you are using, but construct an XML/JSON you can provide as a model/input to mxgraph. I don't want to push you at all. Indeed, there are a couple of caveats:
NOTE: proceed with caution if you reply with quotes. Indeed, if any of these proposals is interesting to you and you agree on the proposed discussion plan, I'd encourage you not to hesitate to open a new thread. I am not sure about where should those be placed, tho. I think that @tgingold will be ok with this thread and the one considering a 'standard' data structure to construct visualizations of code bodies analized by GHDL. However, JavaScript, D3, three, mxgraph, jointjs... might be quite out of scope. In the end, we are trying to build an IDE around GHDL, but it might deserve it's own repo. Let it be Nic30/hdlConvertor, 1138-4EB/elide, Nic30/HWToolkit... Related to #477, ideally I'd like to have a ghdl organization, where we could create ghdl/gui to integrate multiple possibilities. Not only the content discussed here, but also any general topics about using GHDL with GUI tools. For example: how to compile and simulate from Atom or how to set up linting tools. However, in the end, I really don't mind at all. We are talking about 3-6 threads for now. Last thought: keeping a modular approach, but thinking big, do not forget ghdlsynth-beta, icestorm, arachne-pnr, yosys... @flip111 didn't forget about you. The message in the oven is a reply to you. |
|
The main difference or disadvantage of GHDL is that it is not Python. I don't mean this in a case of how it is written, but more in a case that several free cloud services allow us to install Python packages and addons, but no binary code. I'm using a Python based chain of cloud services to do post processing of VHDL source files. I see no way to handle this with GHDL. The second difference is that GHDL (as any compiler) removed comments. As a tool that extracts e.g. documentation from sources, GHDL can not be used. pyVHDLParser e.g. has an generic and abstract description of language constructs. We can move this part to a separate repository so both (or more) projects can use this description. pyVHDLParser does not create a classic AST (Abstract Syntax Tree) as an intermediate representation. It creates a CodeDOM (Code Document Object Model). So modelling does not start at tokens as classical use; it starts at the language model and goes backward to the characters in a file. I think that the later processing steps in pyVHDLParser could use GHDL and pyVHDLParser "frontend" as an input. |
Parser applicationsThe selection of libraries (which were already mentioned) really depend on what you want to do. I see some cons and pros about every library. https://github.com/Nic30/hdlConvertor doesn't support VHDL 2008 but should be fast because it's written in C++. https://github.com/Paebbels/pyVHDLParser supports VHDL 2008 but it's written in python so we can expect it to be slower. (i didn't look into verilog because i'm not familiar with it, but it's also something to consider). Having broad language support is always good to have in any situation (different flavors of vhdl, different flavors of verilig, systemC, clash, ...). But the required parsing speed depends on the application where the parser is used. From slowest (parsing speed doesn't matter much) to fastest (parsing speed is critical)
.. feel free to extend this list with more meaningful parser applications (i can list a few more but i wanted to limit this list to the most interesting once for the moment) IDE
Since you say "build an IDE around GHDL" i assume that you want the IDE to contain a waveform viewer and not just use GHDL for parsing. Ok let's consider building an IDE on top of javascript in two scenario's: IDE in browserYou can't get around building a server-side app to interface with GHDL, python, C++ and various stuff. If you use any of them for the the critical parsing section you have to deal with additional latency of your HTTP request. For this reason editing code in the browser as a real IDE is already out of the window (a real IDE has code analyses on the fly like with vhdl-tool LSP). At best you can do something similar to github which is good enough to make very simple changes to your code. offline IDEYou can still build a real IDE around javascript. The only sane way to do this is to latch onto already existing solutions, which are atom and vscode. I'm not a big fan of them because they are still slow. However it does work quite well and since there are big communities behind them it can only get better. The huge benefit here is that the javascript eco system makes it easy (compared to other solutions) to enhance these editors. My conclusion is that the browser can never be good enough to offer serious IDE functionality (unless you host your server on the same machine of course). And atom/vscode are actually good enough. They are still slow editors but it's easy to push analytics to other tools like GHDL and dedicated parsers. DocumentationFor documentation i would say the browser is the preferred platform. Here you can have written documentation, display code snippets (no editing), display smaller or bigger schematics and sometimes it helps to show a waveform as well. If the IDE solution still uses javascript for the most parts then there is real synergy between an IDE and a documentation viewer. @Paebbels makes a good point here that it's important to be able to host on already existing infrastructure. Since maintaining infrastructure yourself is a day job on itself. What is actually the benefit of GHDL for documentation? For the parsing there are other solutions in competition. So it's main advantage is actually what it was build for generating waveform (simulation). But i think it would be ok if the documentation writer can do the simulation offline and just upload the vcd file along with the documentation. VisualizationIn both IDE setting and documentation setting i think it would be useful to make visualizations in such a way that they allow you to explore the design. Of course a static image is already better than no image. But when doing things in the browser we can do better. I imagine looking at parts of your design and the clicking on the edges to start showing other parts they are connected to. If you want to do this the visualizing library needs to be fast enough for it so you don't have to wait long if your design gets big. I'm not sure which techniques have good hardware acceleration. All the libraries use either WebGL, canvas, SVG or HTML (this is the order i expect them to be fastest to slowest). Though for the moment it would be a waste of time to cook up a custom WebGL solution or something like that. Better go with an already existing solution (Nic30 d3.js or mxgraph or whatever). But it's interesting to see how these libraries respond when you load a big design into it. But for really interesting visualizations let's move on to the next section ... Data flow analysisData flow analysis is something compilers do for any language. In hardware design i think this is done in the elaboration phase (correct me if i'm wrong and it's actually in the analyzing phase). What is interesting about this for visualization (and actually also for when you are working with code) is that it gives more context to your signals. I often see in VHDL code a lot of signals with What data flow analysis would give you is showing you drivers & readers from a signal (a term i picked up from modelsim). By this it would allow you to annotate your signal once on the top entity level "this signal is a clock" and then the data flow analysis would be able to infer all the signals which are derived from this clock. This solution is also not perfect because many drivers can converge on a single reader (using AND/OR gates) and one driver can diverge to many readers (just be the fact that they are connected). Suppose i have After the signal classification phase is done now you can do some really cool things. You can toggle to show a "type of signal" (i'm going to use type here now in the context of how they were classified by you and no longer the actual type in the code). Example "show/hide all clocks". Or maybe "color all clock lines green". Or "show me the data paths in my design". I have actually never seen this done before in such a way so for me it's also a question how well this would work. The technically closest i have seen is modelsim dataflow window. I don't think it's possible to get this information for GHDL at the moment ... but i know it's in there somewhere :P ANTLR
We don't need to "hack" ANTLR, the tool should be able to come up with dedicated parsers for your particular language. At the moment the following code generation targets are available: Java, C#, Python (2 and 3), JavaScript, Go, C++, Swift. From there it's up the the programmer to use these parsers in a tool. For example you could code for a vhdl and verilog parser, then use this code in a CLI tool with a command line option interface. Now you have a CLI tool that can syntax check both VHDL and verilog. The same for if you want to target javascript (in a github editing way scenario). ANTLR is one of the best tools to design parsers. That doesn't mean that there are no other good solutions available (all the parsers there are right now are good parsers). I'm not saying here we should go with ANTLR, i'm just saying that it's good software and it has it's own benefits too. |
IDE
Basic display of components is not a problem. Choice mxgraph/D3.js is invariant.
I tried to use mxgraph json format but I did not found specification of it's json format back in times. Data flow analysis
Without HLS meta-informations and platform-informations you are limited to just view hierarchy design and operator nets. But those informations can be provided by user in form of XDC/ucf... which user probably has. |
#477 is heavy WIP and content from there is being moved to different issues. This is one of them, but also 280, 377, 480... Therefore, content in #477 should not be overlapped with this thread. The only relation is that the possibility to create an organization is listed there, for now, and I'd like #477 is about using docker containers to build (GHDL, that tarballs for releases, ready-to-use images, web sites...). The conceptual IDE we are talking about in this thread will be available as a docker container (mostly because I don't install dev dependencies locally anymore), but I think that it should be deployable "standalone". I use "standalone" because About moving to some now issue to discuss GUI details, as commented above:
Go on! |
|
@flip111, @Nic30, I cleaned the wiki and the develop branch in 1138-4EB/elide. That will allow us to:
If you want, I can add both of you as collaborators. I can't remember now if I stated somewhere my expectations when talking about IDEs: 1138-4EB/elide/wiki/Personal-expectations
Thanks @flip111, I didn't realize that @Nic30 is the same person who wrote about ANTLR4.
Let me elaborate: I don't like huge monolithic tools with heavy dependencies. At the same time, because VHDL projects can get so large and verbose, performance might be an issue. Therefore, I prefer to avoid interpreted languages, such as JavaScript, Python, Ruby... which is quite an issue because... you know... At the same time, instead of very tightly coupled internal modules, I prefer to have some of those intermediate interfaces/APIs exposed so that some or all of the modules can be swapped with alternatives. Kind of 'build your own framework'. This is a compulsory requirement somehow, because we depend on external closed tools for synthesis, P&R and testing. Indeed, both VUnit and PoC are good examples of this approach. As a result, 'lightweight' means to use (multiple) task-specific lightweight tools/libraries in Ada, C, C++, Golang... for the backend (analysis, elaboration, graph layout, waveform generation, waveform format conversion...). If all of these are given in a known format, the frontend can be as lightweight or heavy/performant as wanted. It can be as simple as a CLI or as heavy as a Eclipse mod. Indeed, because VUnit, pyVHDLParser and GHDL are already cli tools, I would forget about the 'lightweight' feature for now, and focus on standard interfaces instead.
Let's start here: NOTE: these are open questions that I will try to respond myself and provide minimal working examples. Of course, I'd be glad to be helped, but I don't expect anyone to do it. As a first example, a full adder was tested with
So many questions. We need to set the requirements, to know if we can get it:
Parser
For me (and I believe that other many will agree) a project started now must support VHDL 2008, and it must expect to support VHDL 2018 as well. I think that weight and performance can be traded, but language support is a must. Which way is faster/better?
I meant this:
I'd drop this feature for now, and expect verilog users to convert their codebase to VHDL. Indeed, I think that VHDL93 or VHDL2002 should be used as standard "HDL netlists". This is somehow true already, since many higher abstraction languages generate VHDL: SpinalHDL/SpinalHDL, clash, myhdl... Indeed, I remember asking @tgingold about using GHDL as a VHDL version conversion tool. That is, input VHDL 2008 codebase and get an equivalent VHDL 2002 or 1993 version. He pointed me to tgingold/ghdlsynth-beta, hence, I think that is the approach to use yosys for synthesis. I wonder how would the generic and abstract description mentioned by @Paebbels fit for this conversion task. I believe this is the same as:
Parser applicationsLet's be more explicit about expected response times:
Can take hours. We want it to take minutes. We'd love to have it done in seconds. Note, it is not the same to generate HTML docs only, or to also generate a PDF with LaTeX in the background. It applies to both text and images.
Must take seconds. We'd love to have it done in less than a second. Indeed, I will :D. Won't switch between code and schematic every second, but have two screens, one showing the (hopefully interactive) schematic and the other with a text editor. Anyway, it can be triggered with a timeout, or a keyboard shortcut, no need for it to be on every file change.
Can take minutes. We want it to take less than a second. We'd to have it done in milliseconds. Using GHDL for formatting was discussed in #464. eclipse/che, which is mentioned in #477, supports LSP. Adding this feature to GHDL is being discussed in #416. VHDL Tool should be mentioned here, even though linting is a premium feature. Also, jeremiah-c-leary/vhdl-style-guide.
As done above, I would set requirements for each feature, independently of having it in a IDE. I think that the IDE should be focused on visualization and automatization, no matter if tasks are fast or slow. I.e., I don't like instant linting, but prefer to use a keyboard shortcut to trigger it fast; hence, I am ok with it taking (tens of) seconds.
If you don't mind, I think it is useful for all of us to have them listed as well. Doing so does not mean we need to integrate them, but allows to have a better big picture. We'll set priorities later, as it seems that each of us is most interested in certain parts of the concept.
IDEIDE in nodejs1138-4EB/elide/wiki/IDE-in-nodejs-electron IDE in browser1138-4EB/elide/wiki/IDE-in-browser Visualization modules/pluginsInteractive tree1138-4EB/elide/wiki/Interactive-tree (RTL) Schematic view1138-4EB/elide/wiki/(RTL)-Schematic-view
For expansion/collapsing, did you see/use the 'container' blocks? In the example you can find them in the 'Advanced' section of shapes:
In the demo above I show some other fancy built-in features:
This last feature is the most interesting to me. Indeed, you can see in the demo that I tried it and forced it to fail by navigating into the container and making the content overflow the original size of the container. This is to show that it is not 'perfect' for our requirements, but it should be relatively easy to fix:
@Nic30 when you say that you didn't solve those problems, do you mean that those are not built-in features or that you couldn't dive into the code far enough to get it done? @Nic30, leaving mxgraph apart, and focusing on your application, which features does it provide? I mean, did you implement every menu and action by hand, or are you using any library? A quick list of features:
Note that not all of them are required. Indeed, some (such as group/ungrouping) can be difficult to translate to hardware. I am trying to guess which 'graphical edition' features you have implemented already. Pipeline mapping and Gantt chart visualization1138-4EB/elide/wiki/Pipeline-mapping-and-Gantt-chart-visualization Waveform viewer1138-4EB/elide/wiki/Waveform-viewer Data flow analysis1138-4EB/elide/wiki/Data-flow-analysis Clocking analysis1138-4EB/elide/wiki/Clocking-analysis Documentation |
|
pyVHDLParser is also a demonstrator. It's meant to allow easy adding and modification of VHDL language features. If the concepts of pyVHDLParser work out, it's possible to translate them e.g. C# There is no intention to be very fast. Being very fast requires heavy optimizations and thus disallows modifications for future language investigations. Doxygen and similar documentation tools are not capable of handling the specifics of VHDL. They are limited to classes and methods. You can not transform VHDL to these paradigms. That's why I prefer e.g. Sphinx and Restructure Text. It can be extended to all needs of VHDL.
pyVHDLParser provides a CodeDOM (semantic object model). It's a object-oriented model of the VHDL source code. It is not specific to any parser or compiler. Read the articles of Ken Beckett for more information.
Yes.
As far as it feels with GHDL: It stops at the first error. pyVHDLParser is more tolerant, because it analyzes many thing in later steps, while more code was already analysed. |
I think we are mixing concepts here. There are two different tasks: i) extract comments and metadata from sources and ii) generate a structured document (HTML and/or PDF) with the extracted info. AFAIK, only Doxygen and similar tools (say VHDocL or gnatdoc) are capable of extracting specially decorated comments from sources. This is true for C-type languages, but also for python and (although buggy) VHDL. A quite different issue is how to elaborate a HTML site or PDF from text-only structured documents. Sphinx, falls in this group, along with Pandoc, LaTeX, Hugo, Jekyll, wikis... Note that there is no relation to the sources, because text-only structured documents are written and updated manually. Note: sphinx can behave as doxygen with python sources, which is what it was created for. It has been extended to support other languages, but the list is quite short compared to doxygen. Then, any of the tools in this last group can be extended to all needs of VHDL, as long as a parser is used to generate intermediate formats (e.g. RestructureText/Markdown). Indeed, because Sphinx is lacking a VHDL domain, extending it is not very different from replacing vhdlparser with a more feature-rich parser. This parser, say pyVHDLParser, needs some mechanism to decide which comments/components should be rendered in the final report and which are to be shown only in source listings. In the end, some syntax must be defined, which will likely conflict or replicate the conventions used by Doxygen. For example, VHDocL, can parse doxygen markup and come with a conversion script. There is also an extension for Sphinx to identify doxygen comments. What is your approach here? Again, I think we should take into account in this thread that services as Travis exists, and can be used as a helper or a replacement for RTD. Is it possible for pyVHDLParser to output an intermediate XML instead of rst sources? With an 'XML to rst' parser it would still fit your workflow. At the same time, it would allow not python-limited environments to use different tools for rendering. |
|
I am back from the dead. Thanks to overloaded semester I now have nearly semester free.
I will allow to edit hwtIde wiki to all. @1138-4eb Nic30/hwtIde - blocks are just hdl components they can be imported/exported etc. (RTL) Schematic view - expanding blocks - I do not know if they can have ports but I will find out
My worst problem was implementation of alg. for initial layout (place components form HDL somehow to have nice diagram with minimum nets crossing). For everything else there is JS lib which can do it.
D3.js
D3.js
all connections are just json, components are placed by A* based alg. to have minimum crossing connections, these connections are just paths between route points rendered by D3.js
css
D3.js
simple JS
D3.js
JS native
in D3.js, not gui accessible yet
simple JS
none (not useful)
D3.js plugin
possible in D3.js, not useful because components should not overlap
Select is done by D3.js and custom JS, it is easy.
Containers are in very early prototype, renderer is just called on box, there is problem with shared history
Done on file-browser level (needs to be on component diagram level)
Done, custom JS, (actually back in time I had to completely rewrite IDE to support this)
Modules are loaded from HDL or can be crafted in GUI, only rectangle shapes yet.
Maybe it would be better to support only hierarchy based layers to keep things simple. Also wires looks like good start. |
care to link your source? Or are you referring to the paper from before? |
|
@flip111 |
|
I created a new repository a couple of days ago, where we can share/integrate the proofs of concept: https://github.com/1138-4EB/hwd-ide It started as a copy of the develop branch and the wiki of 1138-4EB/elide, but I thought it'd be better to use a new repo, because I have some personal unrelated content there. Now we can adapt/reorganize the content to fit the needs of different proofs. @Nic30 and @flip111 were already added as collaborators. If any other wants to contribute, please let us know. The wiki is public, so that anyone can contribute. Indeed, a couple of days ago @Paebbels also created awesome-vhdl. I believe that some of the references in the wiki might be moved there. The same applies to many resources mentioned in this issue. However, I am not sure about the "awesomeness" of all of them, since many are not under active development. @Paebbels, do you think that it would be interesting to add not active/complete projects to the awesome list? I would try to avoid mixing "really awesome" and "not so awesome, but really interesting" efforts, but I think it'd be required to somehow state the status/issues. Right now, there is a single proof of concept that integrates filebrowser/filebrowser with Travis CI is set up to execute two stages after each push to branch develop:
It is ready to start trying to put other stuff together! I believe we can move the conversation here to the new repo. That way, we will produce less "noise" here, and we'll bother Tristan only when we need something related to GHDL. Feel free to open as many issues as you want, as we've talked about many different features. PS: @flip111, @Nic30, I think that all the references here are already present in the wiki of the new repo, but don't hesitate to add any you might miss. |
|
Regarding VHDL parser I have created a new parser project which might be of interest. The current status is that a lot VHDL-2008 is parsed, enough to parse (VUnit, PoC, UVVM, OSVVM). |
|
@kraigher Good. Can you also setup ci (https://travis-ci.com/ etc.) and write some examples? I had 3min and I did not figure out how to use it. |
|
@Nic30 I updated the readme on how to try it out. I will add CI soon. |
|
@Nic30 You can also join the gitter channel https://gitter.im/rust_hdl/Lobby to ask questions and get support. |
|
@Nic30 Now there is Travis CI as well. |
|
@kraigher what data structures are you using for symbol table? |
|
@flip111 A hash table from name to unique_id. Since VHDL is case insensitive symbols that differ only in case get the same id. The id can be used for fast comparison. The code is here: |
|
@kraigher i read elsewhere on the interwebz that vhdl is case insensitive so i don't doubt you about it, but i was curious how it was actually described in the standard. I had a quick look in the 1993 and 2008 standard but i couldn't find it, do you know? Perhaps it might just be so that people think VHDL is case insensitive because a lot of compilers are but it's not defined by the standard. Also with extended_identifier it seems strange to me if it were case insensitive because this is the special case of identifiers in which special characters can be used. So in this case it might also be interesting for the user to differentiate between lowercase and uppercase. Is it already possible with the parser to lookup symbols from different scopes ? |
|
@flip111 Regarding case in-sensitivity the standard does not use this terminology but rather say: LRM 15.4.2 Basic identifiers
Also regarding keywords
LRM 15.4.3 Extended identifiers
So normal identifiers are case insensitive but extended identifiers are not. |
I've been thinking long about having some multiplatform (windows and gnu/linux), free (libre), lightweight and standalone tool to analize large bodies of VHDL 2008 code at block/RTL level. That tool would provide a hierarchy browser of the compiled/synthetized design, so that all the parameterized types and components are resolved. Ideally, the info in the hierarchy would be enough to build a command line tool to draw diagrams with different levels of abstraction (entities, processes and concurrent black boxes) for documentation purposes. As a dream, a GUI could be built with linked references between diagrams and sources.
Among those features, hierarchy browsers are already available in all the big (and heavy) EDA tools and simulators; diagrams and linked references are also supported by most of the big editors. However, most of those tools require several GB to be installed, since they provide lower levels of abstraction and many other utilities. On top of that, the heavy GUIs must be launched even to just analize the hierarchy.
The closest alternative I am aware of is RTLVision. It seems to be very complete technically, it is supported in multiple platforms (windows/linux/solaris), and accepts VHDL, Verilog and System Verilog. Moreover, the engine can be used in many GUI environments. Indeed, I believe it is used by some of the big players in the industry. It is not specified which the supported versions of the standard are, but I believe it should be quite complete for 2008, since they use Verific's parser. However, I don't know how fast it is, given that it accepts multiple languages, and that it includes a waveform viewer to allow signal tracing. In any case, it is neither libre nor free or open source.
There are some projects from academia, such as VHDLVisualizer and HDLVisualizer; and even web solutions: vhdltolatex.mamikon.net. But all of them lack proper language support. Is worth referring to VisualHDL even though its input is THDL++ and outputs VHDL.
A a result, I realized that the starting point should be a reliable VHDL parser. So I searched for free alternatives:
Since I found no valid candidate, I had to accept that parsing VHDL is not straightforward. Some others reached the same conclusion before: Parsing VHDL is [very] hard , A Note on the Parsing of Complete VHDL-2002.
Then, even though ANTLR4 could be the least bad starting point, maybe parsing VHDL with a general purpose engine is not the way to go.
EDIT 2017-12-07 >
Since this first message was posted, I have been informed about new projects:
I think that pyVHDLParser is the best bet. Indeed, if I were to start this thread right now, I would focus on understanding what the differences between GHDL's built-in features and pyVHDLParser are:
NOTE: the rest of this comment are old thoughts, comments and questions that lead to the conclusion above. They are kept because technical details are discussed, which are useful on the path to understand the questions above.
EDIT 2017-12-07 <
Since GHDL is a compiler, it actually parses at least part of the code. It's fast, lightweight, multiplatform, standalone and free. Moreover, it is known for being strict at conforming the standard. I think this is the most valuable feature, given that there already exist multiple incomplete projects which are not expected to be ever improved to this extent.
However, I know nothing about Ada and less about how compilers work. I don't know how much of the structure of the design has to be explicitly known by the GHDL core in order to generate machine code; i.e., whether blocks of VHDL code can be fed directly into an Ada compiler. Anyway, I have analized the content of a library file:
It seems that I could build a hierarchy view of the packages, entities and architectures defined in each file. On top of that, the pretty print command and the cross-reference command syntax highlight every word; the second one also links every identifier (packages, entities, architectures, types, signals...) to it's declaration. Then, although I have not found explicit references in the user guide about how the html is generated, I would say that GHDL could be a good candidate. Nevertheless, the interfacing to other languages section of the user guide explains how to import subprograms, but not how to access to information about the design. I would say that the only choice at now is
AVHPI, which is a very light and slightly adapted version of VHPI. I suppose that it is a very first step forward to something similar to Aldec's VHPI Applications.In the end, the questions:
Although I don't feel confident enough to dive into the sources of GHDL, I wouldn't mind to give Ada a try someweek in the next months. I'd like to have a big picture, to have a better reference of how much time it would require.
The text was updated successfully, but these errors were encountered: