Hello,
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.
# Display every generics and port signals of sub_entity_b_instance
top_level_instance/sub_entity_b_instance:generics
Generics aren't dumped in waveforms as they don't change.
top_level_instance/sub_entity_b_instance:ports
# But exclude inout signals
! top_level_instance/sub_entity_b_instance:ports.inout
# Or should it be
"top_level_instance/sub_entity_b_instance:ports:inout" instead ?
Or should it be:
top_level_instance/sub_entity_b_instance/*:ports:inout
In that case, the meaning of ':' is simply filter out.
# 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.
# Display recursively every signals, variables and generics of every
entity instanciated in sub_entity_c_instance,
# but it won't display anything at first level of
sub_entity_c_instance :
top_level_instance/sub_entity_c_instance/**
# Display a_mem_x and b_mem_y, but not c_mem_x :
top_level_instance/sub_entity_c_instance/[a-b]_mem_*
# Display my_variable from process X1
top_level_instance/sub_entity_c_instance:processes.X1/my_variable
# Or should it be
"top_level_instance/sub_entity_c_instance:processes.X1.my_variable"
instead ?
# Display everything of sub_entity_d_instance recursively, including
what is at first level (*** = * + **) :
top_level_instance/sub_entity_d_instance/***
# But exclude everything from the processes of sub_sub_entity_instance
!
top_level_instance/sub_entity_d_instance/sub_sub_entity_instance:processes
Remarks :
1) The wave signal file should better begin with a version, but it isn't
mandatory. Here is how I plan to do the versioning : First start with
1.0, then 1.1, 1.2, etc as long as the new versions are backward
compatible with the older version. When I do a change in the format that
will break compatibility with an older wave signal file, I will
increment the major version number.
In short :
Currently supported format input file format result
1.5 1.3 OK
1.2 1.4 Error
2.1 1.4 Error
2.1 2.0 OK
Thanks to the versioning, we can give an insighful error to the user in
case of an unsupported input file format version.
Make sense.
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!
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/*:ports
4) I didn't check if GHDL has support for displaying variables from a
process to the waveform
No, only signals and ports are dumped.
PS : Many thanks to Patrick Lehmann for his helpful advices !
Nice teamwork!
Tristan.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
