Hello,
a short remark do generics and constants.
Of cause these signals do not change and in many designs they are fixed values,
but generics might change from instance level to instance level or be different
in instances created within a for... generate loop.
Waveform viewers like iSim and xSim allow the user to display constants and generics, too.
ModelSim has a tool window to display them, but GHDLs primary viewer GTKWave has no
constants window for debugging. Especially, recursive instantiated designs are hard to debug
if one can't see the generic's/constant's values :).
Writing a constant value to VCD like files has no big impact on the file size, because the value
is given as an initial value.
So maybe it's no bad idea, if a user can explicitly enable generic/constant dumping. I see the
biggest problem in displaying such a value, so it doesn't look like a signal in the waveform view.
So as an optional feature, I would vote yes :).
Regards
Patrick
-----------------------------------
Wissenschaftliche Hilfskraft
Technische UniversitÀt Dresden
FakultÀt Informatik
Institut fÃŒr Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden
Tel.: +49 351 463-38451
Fax: +49 351 463-38324
Raum: APB-1020
E-Mail: ***@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
-----Original Message-----
From: Ghdl-discuss [mailto:ghdl-discuss-***@gna.org] On Behalf Of Tristan Gingold
Sent: Sunday, July 03, 2016 6:09 PM
To: ghdl-***@gna.org
Subject: Re: [Ghdl-discuss] Collaboration in the GHDL project
Hello,
Post by Jonas BaggettI 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
# 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.
Post by Jonas Baggett# 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.
Post by Jonas Baggetttop_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.
Post by Jonas Baggett# 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.
Post by Jonas Baggett# 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
top_level_instance/sub_entity_c_instance/**
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,
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:proce
sses
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.
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.
Post by Jonas Baggett2) 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!
Post by Jonas Baggett3) 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
Post by Jonas Baggett4) I didn't check if GHDL has support for displaying variables from a
process to the waveform
No, only signals and ports are dumped.
Post by Jonas BaggettPS : Many thanks to Patrick Lehmann for his helpful advices !
Nice teamwork!
Tristan.