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: patrick.lehm...@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
-----Original Message-----
From: Ghdl-discuss [mailto:ghdl-discuss-boun...@gna.org] On Behalf Of Tristan
Gingold
Sent: Sunday, July 03, 2016 6:09 PM
To: ghdl-discuss@gna.org
Subject: Re: [Ghdl-discuss] Collaboration in the GHDL project
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:proce
> sses
>
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
