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}
# Display every generics and port signals of sub_entity_b_instance
top_level_instance/sub_entity_b_instance:generics
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 ?
# 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
# 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.
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.
3) Here ":<category>" works like a filter that reduce the selection
result to <category>.
4) I didn't check if GHDL has support for displaying variables from a
process to the waveform
PS : Many thanks to Patrick Lehmann for his helpful advices !
Cheers,
Jonas
Le 23. 06. 16 à 08:44, Tristan Gingold a écrit :
On 23/06/16 08:15, Tristan Gingold wrote:
Hello,
I started looking at the ghw waveform generation and I have found the
procedure Wave_Put_Hierarchy_1 in grt-waves.adb where all signals are
extracted from the instance given in parameter. This instance contains
the hierarchy of the design. Before that there is something called
hooks
that initialize all the waveform generators (vcd, ghw, etc) and call
the
initialisation procedure of all the waveform generators (Wave_Start for
the ghw generator which is on the stacktrace of the call to
Wave_Put_Hierarchy_1).
Correct.
My idea was to find the place were the instance is generated before
being available to the waveform generators and to create there another
instance with only the hierarchy of what needs to be displayed as
specified in a text file.
That's what I would do too: create an instance tree from the text file.
Or maybe annotate the existing one with a flag, that would be simpler.
Thinking twice, I am not sure the existing instances can be modified,
they are rodata.
Tristan.
The next step is to make the waveform
generators use this instance instead of the instance with everything.
Here I would differ: pass both trees to the waveform generator and it
will only select the enabled signals.
I believe I have to put this new instance in the Grt.Rtis package.
You shouldn't change grt.rtis as it defines the interface with the
compiler. Create a new package.
At
grt-main.adb, there is a call to Ghdl_Elaborate which execute some code
coming from I don't know where. This code will generate the
instance (as
I believe) and eventually call procedure Ghdl_Rti_Add_Top in
grt-rtis.adb with the generated instance as input parameter.
What I would like to know is where is the code that generate the
instance with the hierarchy of the design and if you think that my
approach is good.
The elaboration code is generated by the compiler.
I think you approach is correct.
Tristan.
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
