On 05/07/16 22:37, Jonas Baggett wrote:
Hello Tristan,
I had some more thoughs on the signal selection for the waveform, and I
made an example of a wave signal file (is there a better english therm
for that ?) that reflects them :
# version 1.5
# Comments begin with #
# Display every signals, variables and generics of
sub_entity_a_instance
top_level_instance/sub_entity_a_instance/*
# But exclude reset and clk
! top_level_instance/sub_entity_a_instance/{reset, clk}
Another way to select several signals in a hierarchy would be through
indentation:
top_level_instance/sub_entity_a_instance/
reset
clk
I am not convinced that this is a better way, it's just for the record.
When there is a long list of signals, it makes sense to have multiple lines.
I am still open with how will be the syntax of the list.
Here is an example of a multiline list of signals :
top_level_instance/sub_entity_a_instance/ {
sub_sub_entity_instance/ {
e, f, g }
h }
That's a very good syntax: clear and compatible with the regexp one.
Or with a more "python-like" approach :
top_level_instance/sub_entity_a_instance/
sub_sub_entity_instance/
e, f, g
h
Humm, I prefer the syntax with curly braces.
# 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.
2) The wave signal file showed above is the final picture as I have
planned, but at the beginning the file format supported will probably be
more basic.
Yes, that's important. No need to have a very powerful feature if
nobody would use all of it. In order of importance:
1) Select a sub part of a design, ie:
top/sub1/sub2/***
2) Select signals at a level, ie:
top/sub1/*
3) Select a particular signal:
top/sub1/sub2/sig1
4) Regexp:
top/sub[1-3]/sig[a-z]
5) Negation
! top/sub2/sigk
Having only 1) would already be great!
I would switch 4 and 5. Both negation and regexp are nice feature to
spare some lines of writing, but I believe negation has a bigger impact
for that purpose and will probably be used more frequently.
If we have for example :
top/***
! top/sub1/sub2/***
it will probably requires a lot more line to do it without the negation
and it will be easy to forget some signals to be saved. Regexp can be
really helpful with "for generates", but otherwise I believe that we can
live without it in most designs. And the negation seems a lot easier to
implement at first glance.
Ok. I don't have a strong opinion of the 4/5 order.
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.
3) Here ":<category>" works like a filter that reduce the selection
result to <category>.
That's clear. But then, what should be written:
top/sub1/arch:ports
top/sub1/arch/*:port
So you mean to write top/sub1/arch/*:ports instead of
top/sub1/arch:ports ? Yes that looks more consistent to me.
Yes.
Tristan.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
