You might be interested in ZamiaCAD, http://zamiacad.sourceforge.net. This is a very well done VHDL (and Verilog soon) IDE. I believe there is a Python script for using the Eclipse GUI with GHDL.
On Tue, Jul 22, 2014 at 2:59 PM, <[email protected]> wrote: > Send Ghdl-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gna.org/listinfo/ghdl-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ghdl-discuss digest..." > > > Today's Topics: > > 1. Re: An Eclipse IDE for GHDL with GTKWAVE integrated > ([email protected]) > 2. Re: An Eclipse IDE for GHDL with GTKWAVE integrated > (Nicole Fontenot) > 3. Re: An Eclipse IDE for GHDL with GTKWAVE integrated (David Koontz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Jul 2014 18:46:48 +0200 (CEST) > From: [email protected] > To: GHDL discuss list <[email protected]> > Subject: Re: [Ghdl-discuss] An Eclipse IDE for GHDL with GTKWAVE > integrated > Message-ID: > < > 327832041.72846269.1406047608878.javamail.r...@zimbra20-e3.priv.proxad.net > > > > Content-Type: text/plain; charset=utf-8 > > > Give me some time to look over the Exuberant Ctags code-base and I'll > > see what I can do. > > Can there be some general discussion with, exactly what are the > > shortcomings of the current parser: > > > > * Is there a problem with ctags not understanding that entity > > blocks and architecture blocks are connected in a fundamental > > way? > > * Are there library functions and constructs that are just too > > much for the current implementation? What do those look like? > > * Is ctags recognition outdated? > > * Is it ctags job to recognize things like flipflops, muxers or > > non-synthesizable constructs? > > >From the discussion, Exuberant Ctags is using regexp to generate tags. > This works, but not very well (for example if you add a newline > or a comment). > The advantage of generating Ctags from ghdl is that this is accurate > and up to date. > > Note that the Ctags technology is somewhat old and poor. We can do > much better to handle hiding, overload and cross-file references. > That's a larger project... > > > I know the topic was on a project of larger scope but, for an IDE > > ctags is an important part of what people expect from one. > > Without good parsing support, the market for the up-and-coming IDE > > will be blas? at best. With this and that I work a full time job in > > mind, > > don't expect sudden results; If there is a wanting for new features I > > will do my best. > > Sure! > > Tristan. > > > > ------------------------------ > > Message: 2 > Date: Tue, 22 Jul 2014 15:10:43 -0500 > From: Nicole Fontenot <[email protected]> > To: GHDL discuss list <[email protected]> > Subject: Re: [Ghdl-discuss] An Eclipse IDE for GHDL with GTKWAVE > integrated > Message-ID: > < > cahjlu7u2xzo++c_wjqgto8ap7m63jyleewme9oo-wya_9p7...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > While ctags has the option to use regex to parse the source files, it is > not what is being used for the vhdl module of ctags. The regex is only > brought into the equation when the tags file is written for vhdl. > > A solution involving ctags would require at least a partial re-parse and > rewrite of the ctags file every time the file buffer is changed. (not a > pretty solution) > > note: (I use token to mean any file data that needs to be kept-track-of.) > > I think a good solution for fixing this problem would be: rewriting the > parser to include token scope, etc. and changing the tags file format, so > the last tab delimited field per line would be a call to an external > program. (do-able but, a bit bulky, and cumbersome) > > > The program would output the location of the tag regardless of white-space > reformatting or comments. > > This would break compatibility I'm almost sure of it. > > > If we were to use GHDL to output all the token locations for each file and > noting scope, the external program for locating the current location of > the token regardless of white-space or comments would still be an essential > tool. > > > On Tue, Jul 22, 2014 at 11:46 AM, <[email protected]> wrote: > > > > Give me some time to look over the Exuberant Ctags code-base and I'll > > > see what I can do. > > > Can there be some general discussion with, exactly what are the > > > shortcomings of the current parser: > > > > > > * Is there a problem with ctags not understanding that entity > > > blocks and architecture blocks are connected in a fundamental > > > way? > > > * Are there library functions and constructs that are just too > > > much for the current implementation? What do those look like? > > > * Is ctags recognition outdated? > > > * Is it ctags job to recognize things like flipflops, muxers or > > > non-synthesizable constructs? > > > > From the discussion, Exuberant Ctags is using regexp to generate tags. > > This works, but not very well (for example if you add a newline > > or a comment). > > The advantage of generating Ctags from ghdl is that this is accurate > > and up to date. > > > > Note that the Ctags technology is somewhat old and poor. We can do > > much better to handle hiding, overload and cross-file references. > > That's a larger project... > > > > > I know the topic was on a project of larger scope but, for an IDE > > > ctags is an important part of what people expect from one. > > > Without good parsing support, the market for the up-and-coming IDE > > > will be blas? at best. With this and that I work a full time job in > > > mind, > > > don't expect sudden results; If there is a wanting for new features I > > > will do my best. > > > > Sure! > > > > Tristan. > > > > _______________________________________________ > > Ghdl-discuss mailing list > > [email protected] > > https://mail.gna.org/listinfo/ghdl-discuss > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: </public/ghdl-discuss/attachments/20140722/1710c4d2/attachment.html> > > ------------------------------ > > Message: 3 > Date: Wed, 23 Jul 2014 09:59:19 +1200 > From: David Koontz <[email protected]> > To: GHDL discuss list <[email protected]> > Subject: Re: [Ghdl-discuss] An Eclipse IDE for GHDL with GTKWAVE > integrated > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > On 22 Jul 2014, at 9:32 pm, Nicole Fontenot <[email protected]> wrote: > > > Give me some time to look over the Exuberant Ctags code-base and I'll > see what I can do. > > Can there be some general discussion with, exactly what are the > shortcomings of the current parser: > > Is there a problem with ctags not understanding that entity blocks and > architecture blocks are connected in a fundamental way? > > Are there library functions and constructs that are just too much for > the current implementation? What do those look like? > > Is ctags recognition outdated? > > Is it ctags job to recognize things like flipflops, muxers or > non-synthesizable constructs? > > I know the topic was on a project of larger scope but, for an IDE ctags > is an important part of what people expect from one. > > Without good parsing support, the market for the up-and-coming IDE will > be blas? at best. With this and that I work a full time job in mind, > > don't expect sudden results; If there is a wanting for new features I > will do my best. > > > > > > I think it would be useful to be able to reference every named object > explicitly or implicitly declared: > > (This from VHDL93) > entity_class ::= [? 5.1] > entity | architecture | configuration > | procedure | function | package > | type | subtype | constant > | signal | variable | component > | label | literal | units > | group | file > (VHDL 2008 adds property and sequence both found in PSL). Notice alias is > missing. > Something like the implicitly declared parameters from a for generation > scheme or loop statement iteration scheme would be clearly out of reach of > a non-thorough parser. I'd suspect labels are too, being context sensitive > used in object declaration as well (constants, signals, variables and > files). > > There's issue both with ctags and any editor understanding scope, > visibility and declarative regions (which would give you the generation or > iteration scheme variables). Even an architecture name exists in a separate > declarative region for component instantiation. Primary units declarative > regions can extend to their secondary units (or a configuration > specification). > > Note there are places where object class defining reserved words (e.g. > signal, variable) are optional (interface lists for entities and functions > ). > > Functions and procedures should be distinct, the former an expression the > latter a statement. > > And how do you distinguish between something in a package declaration and > package body when they can be in two different design files? (e.g. > std_logic_1164.vhdl std_logic_1164_body.vhdl). It looks like name by name > file and line number attributes. > > I don't know about you but I'd love to have an editor that can filter by > entity class for those times you know what something is but don't remember > the exact name. It's faster (for some of us) then coming up with a meta > match value to search with. The existing VHDL tags implementations tend to > pour things into two few a number of cups, IIRC. > > GTKWave has a new dump file format FST, which I've seen in one VHDL > implementation (nvc) and has the ability to point at declarations from the > signals pane, and allows opening an external editor on the declared line > in the declared file. nvc currently only points to declarative regions and > by definition this only covers signals. What's of interest is where the > information comes from - nvc creates a structure containing all the > signals being queued for waveform dump and looks up the location > declarations, it's essentially done from the 'distributed' symbol table the > same way you'd traverse and elaborated model looking for things to 'tag'. > > This also points out you need an elaborated model to get an accurate set > of tags or the ability to superimpose configuration on your results. > There's two few a number of cups in object files too, to distinguish even > object classes (without a naming convention which would be implementation > limited and likely platform limited). > > And the moral here is not meant as discouragement but to encourage working > toward a known goal. Understand how big the problem is. Try for > improvement over the 'state of the art'. > > The last ctags source I have is 5.8 which shows a 29 June 2009 dated for > vhdl.c. It supports limited VhdlKinds: > > static kindOption VhdlKinds[] = { > {TRUE, 'c', "constant", "constant declarations"}, > {TRUE, 't', "type", "type definitions"}, > {TRUE, 'T', "subtype", "subtype definitions"}, > {TRUE, 'r', "record", "record names"}, > {TRUE, 'e', "entity", "entity declarations"}, > {FALSE, 'C', "component", "component declarations"}, > {FALSE, 'd', "prototype", "prototypes"}, > {TRUE, 'f', "function", "function prototypes and declarations"}, > {TRUE, 'p', "procedure", "procedure prototypes and declarations"}, > {TRUE, 'P', "package", "package definitions"}, > {FALSE, 'l', "local", "local definitions"} > }; > > signal is only mentioned as a KEYWORD and recognized. (Ouch!) > > What good are the concepts 'prototype' or 'local' or even distinct > 'record' to someone thoroughly VHDL inculcated? Taking short cuts leads to > substandard editor/IDE support. > > Something free standing can enforce it's will on an editor (GTKWave is an > example). It can coexist with other tools (a plugin in gedit, truly stand > alone, etc., you'd get less usage defining which editor to use). That thing > needs to be thoroughly GHDL aware to be really useful. ctags aren't useful > unless something can take advantage of them and the missing signal is a > good indication of what ctags for VHDL hasn't caught on. (That and for our > own works of VHDL authorship we tend not to need them - we tend to be less > altruistic when there isn't an immediate need). > > Try a gander at OpenGrok's Comparison with Similar Tools for features. > (This link was found on the GNU GLOBAL web page. GLOBAL achieves ctag > compatibility by translation. The big selling point is editor > independence.) > > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: </public/ghdl-discuss/attachments/20140723/ead4b8b6/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss > > > ------------------------------ > > End of Ghdl-discuss Digest, Vol 104, Issue 10 > ********************************************* >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
