On Sun, Oct 30, 2005 at 12:38:17AM +0200, Thomas Sailer wrote: > Hi Tristan, Hello,
> thanks for the new release, and for making your repo public :-) > > I've been quickly trying out 0.20, and have the following remarks: > > It compiles fine for me in i386 fedora core 4 with the current updates. > To compile my testbench, I had to add -lm > to /usr/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/vhdl/lib/grt.lst, because > my testbench uses transcentental functions (sin) from ieee.math_real. You're right. This is now on my TODO list. > The testbench I tried seems to run fine, although I had to modify it > somewhat. At one point it tries to compute real(2 ** 31), which makes > the ghdl compiled binary abort due to an integer overflow. ghdl is > likely right, but modelsim doesn't complain, so I found a bug in my > testbench ;-) Yes, I think 2**31 is not portable. > ghdl 0.20 also compiles on x86_64. Here, I additionally had to add -ldl > to grt.lst, since dlopen and friends are provided there. The testbench It should have been fixed. > also compiles, but the compiled result segfaults early. The backtrace > looks as follows: [...] > The code then tries to fetch Bounds.Dim_1.Length, which it thinks is at > offset 0x10 from the second pointer, where in memory the sought for data > is at offset 0x0c. The end result is that Length fetched is bogus, and > this bogus (huge) value is then used to enlarge the stack (alloca-type > operation), which results in a segfault the first time afterwards an > access of the stack top is attempted (during the next subroutine call). > > It looks to me that the ghdl compiler, which generated the table, and > grt disagree about the size and alignment of Ghdl_Index_Type (grt being > correct, IMO). You're correct. However I think ghdl compiler is correct and Ghdl_Index_Type should be 32bits wide. > After a couple of hours trying to understand the internals of ghdl and > failing, I came up with the following patch (by pure guessing): [...] This patch is correct, however I have preferred to modify grt. I was recently able to use ghdl on another 64bits processor and the small patches are already in SVN. You should try with the latest development version. > This apparently fixes the segfault. Now the following test program at > least runs. The output of value, however, is incorrect, it stays at > zero, and the simulation spews the following messages: > ../../../src/ieee/numeric_std-body.v93:2179:7:@2550ns:(assertion warning): > NUMERIC_STD.TO_SIGNED: vector truncated > > If I uncomment the rng_lib stuff, then the simulation even hangs (i.e. > no progress is made, but CPU is burned). I will try this design. Note that I don't have access on an x86-64. Thanks. Tristan.
