I get a 0 unchanging in a 3.3.29 gtkwave.app I got from the gtkwave sourceforge 
site using Mac OS X 10.7.3 (Lion, x86_64).

Using ghwdump it appears the reals are being declared to the correct value at 
the proper times. ghwdump gives us an independent view of the contents of the 
ghw waveform file.

/Applications/gtkwave.app/Contents/Resources/bin/ghwdump -shtv *.ghw > ghw_dump

  signal s3r: real #39
  signal s4r: real #40
  signal s5r: real #41
  signal s6r: real #42

(e.g. search for #41 following a line containing event time and specifiying 
simulation time)

 At each event time you can see the value of the signals logged against that 
signal (#42 is your real with the fractional part, it shows up in the time 
events and correctly on the waveform display).  The ones without fractions 
(appearing as integers or naturals in ghwdump output) increment by 1 but the 
displayed waveform shows 0, always.

Because ghw is a binary format I hoped it might be easier to diff 3.3.18 and 
3.3.19 and look for collisions with function names in the ghw code in gtkwave.  
No such luck.

The whole thing looks like it might take some analysis for the non-author, 
starting with understanding the ghw format.  There are maybe a dozen lines 
different and involving "ghw" between .18 and .19.   Try diffing src/ghw.c 
between the two.

Tony appears to have switched to svn at 3.3.19.  The cvs tree shows the 
differences between 3.3.18 and 3.3.19 by date (see CHANGELOG.TXT). ghw.c  
changes are describes as +8 -2 lines.  It's describe as:

    added tree allocation pool when misaligned structs are enabled

It seems it's part of something bigger.

(all this on sourceforge)


On May 4, 2012, at 1:35 PM, Dave Webb wrote:

> In-Reply-To: <f5859ca7-cfe0-4d03-b065-0b7018115...@gmail.com>
> 
> Hi there,
> 
> I ran into the same problem as Svenn and I think this might be a
> problem with gtkwave, not with ghdl.
> 
> Converting integers to reals seems to work in ghdl but gtkwave does
> not display them properly.
> The real is stuck to its initial value.
> This is very strange because an unconverted real value is displayed
> correctly (see signal s6r in my testbench).
> 
> I did several tests and I'm pretty sure that this problems is with
> gtkwave >= 3.3.19 only on 64 bit machines.
> gtkwave >= 3.3.19 works fine on 32bit machines.
> 
> I tested 3.3.xx on two 64 bit machines (system (e) and (c)), with xx =
> xx = 10: OK
> xx = 12: OK
> xx = 18: OK
> xx = 19: NOT OK
> xx = 20: NOT OK
> xx = 21: NOT OK
> xx = 24: NOT OK
> xx = 33: NOT OK
> xx = 35: NOT OK
> 
> On a 32 bit machine (system (b))
> 10: OK
> 18: OK
> 19: OK
> 34: OK
> 35: OK
> 
> What I did:
> 1) See real_tb.vhd and make.sh
> These are my testfiles you can use to reproduce the bug.
> 
> 2) My installations
> a) Virtualbox with Debian Wheezy 64 bit
> Linux vm-rca 3.2.0-2-amd64 #1 SMP Sun Apr 15 16:47:38 UTC 2012 x86_64 
> GNU/Linux
> 
> ghdl 0.29
> Architecture: amd64
> Source: ghdl (0.29+gcc4.3.4+dfsg-1)
> Version: 0.29+gcc4.3.4+dfsg-1+b2
> 
> gtkwave 3.3.35
> Architecture: amd64
> Version: 3.3.35-1
> 
> b) Virtualbox with Debian squeeze 32 bit
> Linux rca32 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux
> 
> ghdl 0.29
> Architecture: i386
> Source: ghdl (0.29+gcc4.3.4+dfsg-1)
> Version: 0.29+gcc4.3.4+dfsg-1+b1
> 
> gtkwave 3.3.10
> Architecture: i386
> Version: 3.3.10-1
> 
> c) Virtualbox with Debian squeeze 64 bit
> Linux rca64-test 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012
> x86_64 GNU/Linux
> 
> ghdl 0.29
> Architecture: amd64
> Source: ghdl (0.29+gcc4.3.4+dfsg-1)
> Version: 0.29+gcc4.3.4+dfsg-1+b1
> 
> gtkwave 3.3.10
> Architecture: amd64
> Version: 3.3.10-1
> 
> d) OS X Snow Leopard 64 bit 10.6.8
> gtkwave 3.3.36 (from gtkwave.zip)
> gtkwave 3.3.35 (from homebrew, compiled form updated source)
> 
> On system (b), (c) and (e) the problem occurred when switching from
> gtkwave 3.3.18 to 3.3.19
> It was independent of where the ghw file was created (System (a), (b) or (c)).
> Due to limited disk space I was not able to compile gtkwave on System (a).
> 
> Any suggestions how to fix the problem?
> 
> Kind regards
> 
> Dave
> <real_tb.vhd><make.sh><real_tb.sav>_______________________________________________
> 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

Reply via email to