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.
# Display every input and output signals of sub_entity_b_instance
and all the signals and variables in its architecture
top_level_instance/sub_entity_c_instance:ports.{in, out}
top_level_instance/sub_entity_c_instance:architecture
Honestly, this becomes to complex to me. I am not sure you need that
level of power. But you can still do feature design.
Ok, maybe :ports.in and :ports.out are too much detailed for users
needs, but I believe that :ports and :architecture are useful features.
Sometimes a user is writing some code to interface an entity supposed to
be bug-free or coming from 3rd party. In this case, it makes sense to
save the port signals of this entity and not its internal signals,
because this doesn't need to be tested and investigated but the code
that interfaces it.
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.
One future step could be to write also a GtkWave save file to have the
signals displayed in the right order and right format without extra work
for the user with the exception of the signal formatting that needs to
be specified in the trace configuration file.
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 ?
PS : Good luck for France tonight ;).
Jonas
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
