Hello, Guest the thread was called1.1k times and contains 26 replays

last post from Ben-401 at the

build errors

    Aah, finally, I'm hitting some paydirt with my cygwin-windows efforts! :) Note quite there yet, but getting closer :) :)

    Today, I aimed to build the gcc-version of ghdl via cygwin. Here's a summary of the steps that worked out for me (I'll try refine these steps on the wiki eventually):

    [Pre-reqs]
    run the cygwin setup exe and install the following:
    - gcc-g++
    - gcc-ada
    - gmp-devel
    - mpfr-devel
    - libmpc-devel
    - wget
    - git

    1) Grab the source for gcc v4.9.3
    - cd ~/Downloads
    - wget http://mirror.aarnet.edu.au/pu…cc-4.9.3/gcc-4.9.3.tar.gz
    - mkdir gcc
    - cd gcc
    - tar xvf ../gcc-4.9.3.tar.gz
    (wait patiently for it all to decompress)

    2) Grab the latest version of ghdl via git and copy its source into gcc
    - cd ~/Downloads
    - git clone http://git.code.sf.net/p/ghdl-updates/ghdl-updates.git ghdl-updates
    - cd ghdl-updates
    - ./configure --with-gcc=$HOME/Downloads/gcc/gcc-4.9.3
    - make copy-sources

    3) Build and install gcc+ghdl
    - cd ~/Downloads/gcc/
    - mkdir gcc-objs; cd gcc-objs
    - ../gcc-4.9.3/configure --prefix=/opt/gcc-4.9.3 --enable-languages=c,vhdl --disable-bootstrap --disable-lto --disable-multilib
    - make -j2
    - make install
    - rm /usr/bin/ghdl
    - ln -s /opt/gcc-4.9.3/bin/ghdl.exe /usr/bin/ghdl
    - As a test, try typing "ghdl --disp-config"
    - take a look at the output, and assure that there's no text anywhere that says "ghdl: installation problem:". If not, your ghdl exe is good to go! :)

    4) Take it for a spin!
    - cd "$HOMEPATH/My Documents/mega65"
    - make simulate
    - this churns away at quite a lot of *.vhdl files this time, no errors given
    - then you will get a "cpu_test.exe" file
    - Then give Paul's suggestion a try, of:

    ./cpu_test.exe | grep gs4510 | grep MAP

    For me, this churned away for a while, and then resulted in this error:

    ./cpu_test:error: bound check failure at bitplanes.vhdl:267
    ./cpu_test:error: simulation failed

    Aah, but that's ok, at least it's a human-readable error and something I can chase up :)

    Whew, it's *almost* working then! :D

    Ok, looking deeper into it now. I noticed that "cpu_test.exe" is outputting everything to stderr instead of stdout, so I ran it with a bit of redirection so that the greps behaved themselves:

    ./cpu_test.exe 2>&1 | grep gs4510 | grep MAP

    I now see it successfully ran through a few commands before dying:

    Code
    1. %gs4510.vhdl:915:9:@980ns:(report note): $8100 4C D3 8C jmp $8CD3 gs4510.vhdl:915:9:@1060ns:(report note): $8CD3 78 sei gs4510.vhdl:915:9:@1220ns:(report note): $8CD4 A9 00 lda #$00 gs4510.vhdl:915:9:@1500ns:(report note): $8CD6 8D 00 BF sta $BF00gs4510.vhdl:915:9:@1900ns:(report note): $8CD9 4C E5 8C jmp $8CE5gs4510.vhdl:915:9:@2220ns:(report note): $8CE5 20 8E 8C jsr $8C8Egs4510.vhdl:915:9:@2300ns:(report note): $8C8E 78 sei gs4510.vhdl:915:9:@2380ns:(report note): $8C8F D8 cld gs4510.vhdl:915:9:@2460ns:(report note): $8C90 03 see gs4510.vhdl:915:9:@2540ns:(report note): $8C91 38 sec gs4510.vhdl:915:9:@2860ns:(report note): $8C92 20 EC 95 jsr $95ECgs4510.vhdl:915:9:@3180ns:(report note): $95EC B0 06 bcs $95F4gs4510.vhdl:915:9:@3340ns:(report note): $95F4 A9 47 lda #$47 gs4510.vhdl:915:9:@3620ns:(report note): $95F6 8D 2F D0 sta $D02Fgs4510.vhdl:915:9:@3780ns:(report note): $95F9 A9 53 lda #$53 gs4510.vhdl:915:9:@4060ns:(report note): $95FB 8D 2F D0 sta $D02Fgs4510.vhdl:915:9:@4460ns:(report note): $95FE 60 rts gs4510.vhdl:915:9:@4860ns:(report note): $8C95 AD 31 D0 lda $D031gs4510.vhdl:915:9:@5020ns:(report note): $8C98 09 40 ora #$40 %

    Anyway, back to that error:

    Code
    1. %./cpu_test:error: bound check failure at bitplanes.vhdl:267./cpu_test:error: simulation failed%

    I took a look at this "bitplanes.vhdl" file, line 267 reads:

    Code
    1. %bitplanes_byte_numbers(i) <= bitplanes_byte_numbers(i) + 1;%

    I had a look at Paul's prior commits relating to out-of-bounds stuff and I guessed it might have something to do with how the signal was defined:

    Code
    1. % type bitplane_offsets_8 is array(0 to 7) of integer range 0 to 511; signal bitplanes_byte_numbers : bitplane_offsets_8;%

    I haven't looked at vhdl for a while, so I'll save that for my next learning spurt. But in the interim, if Paul, Deft, or anyone else has any ideas on it? I'd be happy for some input :)

    Ok, thought I'd focus back on the last ghdl error I saw:

    Code
    1. %./cpu_test:error: bound check failure at bitplanes.vhdl:267./cpu_test:error: simulation failed%

    Taking a look inside "bitplans.vhdl:267", the culprit line is:

    Code
    1. %for i in 7 downto 0 loop... ===>>> bitplanes_byte_numbers(i) <= bitplanes_byte_numbers(i) + 1; <<<=== (line 267)...%

    So, some sort of loop thingie, right. I learnt that from the existing code the "report" command can output readable strings in the ghdl output, so that seemed liked a good way to go with debugging. I added this line to precede line 267:

    Code
    1. %report "BEFORE: bitplanes_byte_numbers(i) = " & integer'image(bitplanes_byte_numbers(i));%

    I built and ran cpu_test.exe again and saw that it dies when bitplanes_byte_numbers(i) = 511.

    Aah, so it could only hold a value from 0-511, and adding 1 caused the "bound check failure" error...

    Hmm, part of me felt that maybe GHDL was just being hyper-sensitive about this stuff, and on the real synthesised system, this would be just fine? (I'm guessing it'll just loop over back to zero there without any complaint?)

    Ah well, anyway, to keep ghdl happy, I tweaked the code to the following instead:

    Code
    1. %if bitplanes_byte_numbers(i) = 511 then bitplanes_byte_numbers(i) <= 0else bitplanes_byte_numbers(i) <= bitplanes_byte_numbers(i) + 1;end if;%

    I ran cpu_test again, ah great, this worked around the problem fine. Then a similar bounds-check error got reported in "viciv.vhdl:3561", worked around it in the same way.

    I ran cpu_test again, it progresses further, this time dies on this:

    Code
    1. %debugtools.vhdl:26:9:@182700ns:(assertion error): HWRITE Error: Trying to read vector with an odd (non multiple of 4) length./cpu_test:error: NULL access dereferenced./cpu_test:error: simulation failed%

    I'll ponder this next... Still, part of me wonders if this is ghdl being oversensitive again and that maybe there's some parameter I can feed it to tell it not to be so sensitive. Ah well, let's see... :)

    To try figure out that last error, I was hoping to get a vhdl backtrace at the point the assert error hit.

    This thread had a few tips on how to go about this:

    - https://sourceforge.net/p/ghdl-updates/tickets/54/

    The best backtrace support in ghdl presently only seems to be available with the llvm backend (unfortanately, I've got ghdl with gcc backend). So I had to make do with the suggested gdb approach:

    1) I edited the Makefile and added the "-g" flag to the simulate recipe:

    simulate: $(SIMULATIONFILES)
    ghdl -i $(SIMULATIONFILES)
    ghdl -m -g cpu_test

    Not sure if this was necessary, but they made a mention of it...

    2) ran "make simulate" to get a new "cpu_test.exe"

    3) gdb ./cpu_test.exe 2>err.log

    4) Their initial suggestion was to do "break do_report", but that seems to trigger on just about every line of debug output (way too often).

    So instead, I did a break at a point further inside this do_report() function where it did a report for Severity/Level=error(3) (as this was an error assert, and not just a note or warning).

    - break grt-lib.adb:68
    - r
    - backtrace

    This got me a fairly ugly-looking gdb backtrace, which I'll manually tidy up to the following:

    #1 work__debugtools__hwrite at debugtools.vhdl:26
    #2 work__debugtools__to_hstringO1 at debugtools.vhdl:72
    #3 work__debugtools__to_hstringO2 at debugtools.vhdl:80
    #4 work__ram8x32k__ARCH__behavioural__P0__PROC at ghdl_ram8x32k.vhdl:48

    Taking a look inside "ghdl_ram8x32k.vhdl", it's triggered by a call to report within this section:

    Code
    1. % if(rising_edge(Clka)) then if ena='1' then if(wea="1") then ram(to_integer(unsigned(addra(14 downto 0)))) <= dina; report "COLOURRAM: A writing to $" & to_hstring(unsigned(addra)) & " = $" & to_hstring(dina); end if; end if; end if;%

    I'll try debug this further tomorrow and see why it's tripping up here...

    After noticing the google-groups site has more of a "devs" focus, and this forum site more of an "end-user" focus, I reckon it's time to move my incremental build-error details over to google-groups, to this thread:

    https://groups.google.com/foru…s-development/q7kCars2Xqw

    If you found this sort of detail useful/interesting, you're welcome to follow along there.

    If it was never your cup of tea, then you can breathe a sigh of relief now :D