Hello,
I think, if an interface is required, it should export a DOM not the AST. ASTs are parser specific and hard to read. I don't know the AST of GHDL, but I had to use other ASTs which needed a lot of work to read/parse them.
The lately announced pyVHDLParser has a VHDL DOM (Document Object Model). This model is fixed for VHDL-2008 and does not depend on the parser. So other parsers could generate the same model. It's simple to translate this model to Ada or C.
A DOM doesn't containt resolve names or types, it's a compact in-memory representation of a single VHDL file. It comes with methods to find information like GetObjectOfLabel("baz").
document
o- entity
o- name: "foo"
o- libraries
o- "ieee"
o- uses
o- "ieee.std_logic_1164.all"
o- "ieee.numeric_std.all"
o- ports o- port
o- name: "clk"
o- type: "std_logic"
-----------------------------------
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351 463-38324
E-Mail: patrick.lehm...@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
o- architecture
o- name: "rtl"
o- entity: "foo"
o- libraries
o- uses
o- declared-items
o- constant
o- name: "bar"
o- type: "integer"
o- init-value: 5
This could also be exported as XML, JSON, ...
My model for pyVHDLParser is still in development, but one can look into the code and get an impression of a DOM:
https://github.com/Paebbels/pyVHDLParser/blob/master/pyVHDLParser/Model/VHDLModel.py
Sorry I have no picture available, but running the Frontend.py with simple_1.vhdl in mode 32 would present a first translation into the mentioned DOM :).
Such a DOM could already be useful for many applications, but most of the emails here demand for a complete design model ...
It should also be possible to generate a resolved model. So multiple files are combined, symbols are resolved, constants are propagated and e.g. unused generate statements are removed. I hope I can show results for that design model in a few weeks :).
@Tristan: Has GHDL such a DOM? How complex is it to translate the internal structure to such a DOM?
I could e.g. assist in translating the Python model into an Ada model.
Kind regards
Patrick
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351 463-38324
E-Mail: patrick.lehm...@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Adrien Prost-Boucle
Datum:05.10.2016 19:36 (GMT+01:00)
An: GHDL discuss list
Betreff: Re: [Ghdl-discuss] Re: Synthesis for FPGAs
Hi,
> > But if adding a fourth "flavour" is possible - in addition to gcc,
> > llvm and mcode -
> > which would be generation of shared lib of the parser (or anything
> > not gcc or llvm specific)
> > + corresponding headers for C/C++/bindings-for-your-preferred-
> > language,
> > then it would certainly be of great help for many synthesis and
> > design instrumentation projects
> > (there are many in my lab, even if I'm not working on that).
> >
> > Also YG: such a lib would also certainly be of great help to create
> > your virtual machine
> > as a new systhesis tool attempt :-)
> >
> > Tristan: How hard would it be to add such a "shared lib" flavour?
>
> Creating a binding to the AST, or dumping the AST in XML or JSON
> would
> be very easy.
>
> The problem is that the AST is not very stable and change frequently.
If the AST changes frequently, then it's a problem if it's dumped in
some format for other tools to parse. Because the tools would be
compiled for a certain version of GHDL in mind, but the GHDL version
installed on the machine may not be the same.
Hence the idea of having the parsing stuff of GHDL being compiled as a
library, static or dynamic. Third-party tools would be compiled and
linked with that lib.
If static lib, no problem, the parser is then embedded in the third-
party tool.
If dynamic lib, then the tools would be linked the appropriate version
of the lib and many versions of the lib can coexist in your system
/*/lib/ directory.
This is why I think having the possibility of generating a lib from
GHDL (at least parser and walk/introspection functions for the AST)
would be key for any other third-party tools, independent of them being
synthesis / simulation / translation / instrumentation tools / wierd
experimental virtual machine emulation stuff.
Regards,
Adrien
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
> > But if adding a fourth "flavour" is possible - in addition to gcc,
> > llvm and mcode -
> > which would be generation of shared lib of the parser (or anything
> > not gcc or llvm specific)
> > + corresponding headers for C/C++/bindings-for-your-preferred-
> > language,
> > then it would certainly be of great help for many synthesis and
> > design instrumentation projects
> > (there are many in my lab, even if I'm not working on that).
> >
> > Also YG: such a lib would also certainly be of great help to create
> > your virtual machine
> > as a new systhesis tool attempt :-)
> >
> > Tristan: How hard would it be to add such a "shared lib" flavour?
>
> Creating a binding to the AST, or dumping the AST in XML or JSON
> would
> be very easy.
>
> The problem is that the AST is not very stable and change frequently.
If the AST changes frequently, then it's a problem if it's dumped in
some format for other tools to parse. Because the tools would be
compiled for a certain version of GHDL in mind, but the GHDL version
installed on the machine may not be the same.
Hence the idea of having the parsing stuff of GHDL being compiled as a
library, static or dynamic. Third-party tools would be compiled and
linked with that lib.
If static lib, no problem, the parser is then embedded in the third-
party tool.
If dynamic lib, then the tools would be linked the appropriate version
of the lib and many versions of the lib can coexist in your system
/*/lib/ directory.
This is why I think having the possibility of generating a lib from
GHDL (at least parser and walk/introspection functions for the AST)
would be key for any other third-party tools, independent of them being
synthesis / simulation / translation / instrumentation tools / wierd
experimental virtual machine emulation stuff.
Regards,
Adrien
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
