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