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 }
Or with a more "python-like" approach :
top_level_instance/sub_entity_a_instance/
sub_sub_entity_instance/
e, f, g
h
# 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.
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.
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.
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.
Cheers,
Jonas
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
