On 07/07/16 18:50, Jonas Baggett wrote:
Hello Tristan,
There is also the case of signals in a package : I would suggest the
following syntax : pkg.the_signal. It seems better to me than
/pkg/the_signal.
Why ? /pkg/the_signal is more regular.
Note you can have two packages with the same name in two different
libraries, so maybe it should be /lib/pkg/the_signal. It is also
possible for an entity to have the name of a library, so maybe it
should be /@lib/pkg/the_signal. At this point we almost follow
the syntax of external path names except '/' is used instead of '.'.
Yes, but this is already handled by: top/sub1/*
So I don't see a real need for :ports
Could you explain me that a little more ? Because top/sub1/* will select
all signals from sub1, which means port and internal signals. So without
:ports, I don't see a way to display only port signals of an entity
without indicating explicitely all of them. :ports and :architecture
aren't anyway a top priority feature in my eyes.
Yes, you're right. I have forgotten internal signals.
I think the opposite would be better: be able for ghdl to read a
gtkwave save file and dump only the needed signals.
I think this is more natural for the users: they dump all signals and
then to speed-up simulation, select only a subset of signals.
Everything is done graphically. That's also the reason why I think
the syntax of the selection file should be simple, because they will
be generated by waveform display tools rather than written by users.
Parsing the .gtkw files is easy: just discard uninteresting lines and
chars.
I believe that the ideal solution would be to use gtkwave as a library
so that GHDL can have control on it. It could launch gtkwave and
directly add waves to it. In the end, no .gtkw file would be needed :
GHDL will load trace options in a human readable format, give them to
gtkwave, then when the user changes trace options on gtkwave and save
them, GHDL will receive these changes and store them in its human
readable format. How do you think about that ? And is it possible to do
that with gtkwave ?
That's very ambitious! I don't know gtkwave well enough to comment
about that. But having an integrated IDE would be nice.
PS : Good luck for France tonight ;).
Usually France looses against Germany :-(
Tristan.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
