Re: [Ghdl-discuss] Signal selection in wave

2016-11-01 Thread Tristan Gingold

On 01/11/16 21:08, Jonas Baggett wrote:

Hello,

With the last git version of GHDL, there is a new --write-opt-file
option that will create a wave option file with all the signals of the
design.

Please note that there is a backward incompatible change as the
--wave-opt-file option is renamed to --read-opt-file for consistency !


Now you can do :

ghdl -r  --write-opt-file=trace.txt --wave=wave/toto.ghw

In order to write the path of all the signals of the design in the file
trace.txt.


Then you can edit this file and remove unneeded signals, then read it
with the following command :

ghdl -r  --read-opt-file=trace.txt --wave=wave/toto.ghw


Currently there is a known issue with for generates as it is impossible
to select the instantiation of a particular index, but it is planned to
be fixed.


Thank you Jonas for all this work!

Tristan.


___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss


Re: [Ghdl-discuss] Signal selection in wave

2016-08-06 Thread Jonas Baggett

I just saw that in the wikipedia page of gtkwave :

˝Coupled with the GtkPlug mechanism, this allows for the viewer to be 
integrated with other simulators in order to provide an interactive 
environment all in one window.Tcl 
scripting and callback capability 
allow for remote control by other applications. Starting with the 3.3 
series,Bluespec Workstation is 
able to start GTKWave from the workstation, send signals from the 
workstation to the waveform viewer, and display mnemonics for enumerated 
types, structured buses, etc.˝


It seems that is exactly what I need :-).


Le 03. 08. 16 à 23:51, Adrien Prost-Boucle a écrit :


<...>

GTKWave used as a library:
For this to be done the right way I suspect GKWave developers have their word 
to say ;-)

<...>
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss


Re: [Ghdl-discuss] Signal selection in wave

2016-08-03 Thread Adrien Prost-Boucle
Hi,

These are great features, the kind that will probably put GHDL/GTKWave in much 
better place among simulation tools :-)
Here are my comments.

V1.1: Double wildcards
I understand /top/**, top/sub*/**, top/*/**
But it means we have to set something for each path "depth" to select "leaf" 
signals.
So these would also be very useful: /top/**/data*, **/instance_i/*

V1.3: Selecting of element in an array
Yes it is important IMO.
Most often for debug, when a design embeds a memory you are only interested in 
a subset of the cells.
Also, with generics it's very frequent the have large signals/ports with size 
WIDTH*NB,
and similarly we are often interested in a subset of that large width.
For very long simulations this can save a notable amount of waveform data.

V1.4: selection of ports
Yes they are always extremely important.
However I don't unserstand why a specific syntax is needed?
As far as I know, port names and signal names can't be same.

GTKWave used as a library:
For this to be done the right way I suspect GKWave developers have their word 
to say ;-)

Best regards,
Adrien

On Wed, 2016-08-03 at 22:34 +0200, René Doß wrote:
> Hallo Jonas,
> 
> sounds good your plan.
> What are double wildcard?
> 
> My human opinion 
> V1.4 ports are always important. This feature comes to late.
> V1.3 selection of an element in array is not needed. If I have an array
> I have an address and a write signal. Then I research contents in an
> array I have a look on this address an write signal.
> 
> 
> 
> Am 03.08.2016 um 21:54 schrieb Jonas Baggett:
> > Hello,
> > 
> > So here is an updated roadmap for signal selection in wave.
> > 
> > + When the wave option file given to the command line doesn't exist,
> > it should be created with all the signals of the design.
> > 
> > + Version 1.1 :
> >  - Simple wildcards (/top/sub1/*, /top/sub*/*)
> >  - Double wildcards (/top/**, top/sub*/**, top/*/**)
> > 
> > + Version 1.2 :
> >  - Simple regexp (top/sub[1-3]/sig[a-z])
> >  - Negation (! top/sub2/sigk)
> > 
> > + Signals in shared memory (as suggested by René)
> > 
> > + Version 1.3 :
> >  - Selecting element in an array (/top/sub3/my_array(5))
> >  - Selecting element in a record (/top/sub3/my_record.field)
> > 
> > + Version 1.4 :
> >  - Selection of port and architecture signals
> > (top/sub1/arch/*:port and top/sub1/arch/*:architecture)
> > 
> > + When possible :
> >  - gtkwave used as a library ?
> > 
> > Thanks for your comments.
> > 
> > Jonas
> > 
> > 
> > Le 26. 07. 16 à 22:42, René Doß a écrit :
> > > 
> > > Am 25.07.2016 um 21:09 schrieb Jonas Baggett:
> > > > Hello Rene,
> > > > 
> > > > That's an interesting feature for long simulations, thanks for the
> > > > information.
> > > I have missed this feature, as I wrote some state machines. Often I had
> > > a state and waiting for for a condition that never come. I could stop my
> > > simulation earlier.
> > > 
> > > > Do you also know if gtkwave could be used as a library ?
> > > I do not know this. I think not. The source code is open source.
> > > 
> > > > So that ghdl could directly launch gtkwave and add signals to it and
> > > > then when the user makes some changes in gtkwave and save them, ghdl
> > > > will be able to receive these changes.
> > > > 
> > > You want a use gtkwave as manipulator. Interesting idea.
> > > This is total new feature. great idea.
> > > 
> > > René
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > Jonas
> > > > 
> > > > 
> > > > Le 24. 07. 16 à 15:26, Rene Doss a écrit :
> > > > > > > Tell me if you have any suggestion.
> > > > > yes I have something, but I do not know if this the correct discussion
> > > > > round.
> > > > > 
> > > > > I say something what I have seen for long time. This information is
> > > > > from
> > > > > my deeper brain.
> > > > > 
> > > > > Gtkwave has included shared memory functions. (I think it is only
> > > > > possible under linux)
> > > > > If ghdl can store the signal in a shared memory the current signals
> > > > > can
> > > > > be refreshed by gtkwave directly into the screen. This is interacting
> > > > > process. The use can follow the simulation online.
> > > > > 
> > > > > 
> > > > > Rene
> > > > > 
> > > > > ___
> > > > > 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
> > > 
> > 
> > 
> > ___
> > Ghdl-discuss mailing list
> > Ghdl-discuss@gna.org
> > https://mail.gna.org/listinfo/ghdl-discuss
> 
> 
> ___
> 

Re: [Ghdl-discuss] Signal selection in wave

2016-08-03 Thread René Doß
Hallo Jonas,

sounds good your plan.
What are double wildcard?

My human opinion 
V1.4 ports are always important. This feature comes to late.
V1.3 selection of an element in array is not needed. If I have an array
I have an address and a write signal. Then I research contents in an
array I have a look on this address an write signal.



Am 03.08.2016 um 21:54 schrieb Jonas Baggett:
> Hello,
>
> So here is an updated roadmap for signal selection in wave.
>
> + When the wave option file given to the command line doesn't exist,
> it should be created with all the signals of the design.
>
> + Version 1.1 :
>  - Simple wildcards (/top/sub1/*, /top/sub*/*)
>  - Double wildcards (/top/**, top/sub*/**, top/*/**)
>
> + Version 1.2 :
>  - Simple regexp (top/sub[1-3]/sig[a-z])
>  - Negation (! top/sub2/sigk)
>
> + Signals in shared memory (as suggested by René)
>
> + Version 1.3 :
>  - Selecting element in an array (/top/sub3/my_array(5))
>  - Selecting element in a record (/top/sub3/my_record.field)
>
> + Version 1.4 :
>  - Selection of port and architecture signals
> (top/sub1/arch/*:port and top/sub1/arch/*:architecture)
>
> + When possible :
>  - gtkwave used as a library ?
>
> Thanks for your comments.
>
> Jonas
>
>
> Le 26. 07. 16 à 22:42, René Doß a écrit :
>>
>> Am 25.07.2016 um 21:09 schrieb Jonas Baggett:
>>> Hello Rene,
>>>
>>> That's an interesting feature for long simulations, thanks for the
>>> information.
>> I have missed this feature, as I wrote some state machines. Often I had
>> a state and waiting for for a condition that never come. I could stop my
>> simulation earlier.
>>
>>> Do you also know if gtkwave could be used as a library ?
>> I do not know this. I think not. The source code is open source.
>>
>>> So that ghdl could directly launch gtkwave and add signals to it and
>>> then when the user makes some changes in gtkwave and save them, ghdl
>>> will be able to receive these changes.
>>>
>> You want a use gtkwave as manipulator. Interesting idea.
>> This is total new feature. great idea.
>>
>> René
>>
>>
>>
>>
>>
>>> Jonas
>>>
>>>
>>> Le 24. 07. 16 à 15:26, Rene Doss a écrit :
>> Tell me if you have any suggestion.
 yes I have something, but I do not know if this the correct discussion
 round.

 I say something what I have seen for long time. This information is
 from
 my deeper brain.

 Gtkwave has included shared memory functions. (I think it is only
 possible under linux)
 If ghdl can store the signal in a shared memory the current signals
 can
 be refreshed by gtkwave directly into the screen. This is interacting
 process. The use can follow the simulation online.


 Rene

 ___
 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
>>
>
>
> ___
> 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


Re: [Ghdl-discuss] Signal selection in wave

2016-07-25 Thread Jonas Baggett

Hello Rene,

That's an interesting feature for long simulations, thanks for the 
information. Do you also know if gtkwave could be used as a library ? So 
that ghdl could directly launch gtkwave and add signals to it and then 
when the user makes some changes in gtkwave and save them, ghdl will be 
able to receive these changes.


Jonas


Le 24. 07. 16 à 15:26, Rene Doss a écrit :

Tell me if you have any suggestion.

yes I have something, but I do not know if this the correct discussion
round.

I say something what I have seen for long time. This information is from
my deeper brain.

Gtkwave has included shared memory functions. (I think it is only
possible under linux)
If ghdl can store the signal in a shared memory the current signals can
be refreshed by gtkwave directly into the screen. This is interacting
process. The use can follow the simulation online.


Rene

___
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


Re: [Ghdl-discuss] Signal selection in wave

2016-07-24 Thread Rene Doss
>>Tell me if you have any suggestion.
yes I have something, but I do not know if this the correct discussion
round.

I say something what I have seen for long time. This information is from
my deeper brain.

Gtkwave has included shared memory functions. (I think it is only
possible under linux)
If ghdl can store the signal in a shared memory the current signals can
be refreshed by gtkwave directly into the screen. This is interacting
process. The use can follow the simulation online.


Rene



Am 23.07.2016 um 11:21 schrieb Jonas Baggett:
> Hello,
>
> I made a roadmap for the signal selection feature :
>
> Version 1.0 :
> - Finishing code review with Tristan
> - Add signal selection support for other format than ghw
> - Add a help description in Simulation_and_runtime.rst and
> grt-options.adb
> - Should I add a wave option file example in doc/ too ?
>
> Version 1.1 :
> - Create an option that works like --disp-tree but prints the design
> tree in
> the wave option file format (could be in 1.0 too).
> - Simple wildcards (/top/sub1/*, /top/sub*/*)
> - Double wildcards (/top/**, top/sub*/**))
> Remark : *** is no more needed since ** will have it's behavior and
> the old
> behavior of ** can be achieve with */** (top/*/**) which makes more
> clear that
> we aren't displaying any signals in the first level of /top
>
> Version 1.2 :
> - Simple regexp (top/sub[1-3]/sig[a-z])
> - Negation (! top/sub2/sigk)
>
> Version 1.3 :
> - Selecting element in an array (/top/sub3/my_array(5))
> - Selecting element in a record (/top/sub3/my_record.field)
>
> Version 1.4
> - Selection of port and architecture signals
> (top/sub1/arch/*:port and top/sub1/arch/*:architecture)
>
> Tell me if you have any suggestion.
>
> Jonas
>
> ___
> 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