Hi all,
I am currently working on porting some code on microblaze from a
spartan 3 FPGA to a virtex 2 pro FPGA for expansion reasons. The code
which really works on a spartan 3 FPGA, just somehow does not seem to
work on the virtex 2 pro. Here are some details:

1) for the spartan 3 FPGA, I used both EDK9.1i+ISE 7.1i and EDK9.2i
+ISE9.2i
the same firmware running on the spartan works fine.
2) I ported exactly the same architecture + firmware + EDK9.1i, since
EDK9.2i does not support virtex 2 pro yet. which is really
disappointing
3) my hardware architecture is like this; the hardware peripherals are

when using EDK9.2i and spartan 3
- microblaze v7.0 with plb bus
- a UART peripheral, modified to perform hardware handshaking
- this works fine

when using EDK7.1i and spartan 3
- microblaze v4.0 with opb bus
-a UART peripheral, modified to perform hardware handshaking
- this works fine

when using EDK9.1i and virtex 2 pro
- microblaze 6.0
- a UART peripheral, modified to perform hardware handshaking
- this does not work, the algo does not return correct data at all.

4) my software design flow looks like the one below. No interrupt is
used.

int main(){
get_params(); //get data from UART using blocking statements
start_algo(); //to start algo
return_result(); //return results back to PC via UART.
}

void start_algo(){
// I inserted a breakpoint around here.
...the rest of the algo....
}


5) I have tested that
int main(){
get_params(); //get data from UART using blocking statements
return_result(); //return results back to PC via UART.
}

works. So the problem is not with the UART data transfer.

6) how i know it does not work
a) wrong data is sent back from the virtex 2 pro board back to PC.
b) when I sent the compilation switch to no optimisation, the problem
gets worse. No data is sent back at all to PC.
again to iterate, the same firmware works on spartan 3, using EDK9.2i
(microblaze 7) and EDK7.1i (microblaze 4). now, it does not work on
EDK9.1i (microblaze 6).

if things are not already bad enough, when doing debugging using the
mdm hardware debugger, stepping sometimes already results in the
program jumping to some other routine that does not correspond to the
software flow. I am equally cluelss about this.

this subject is related to one that i posted 2 weeks ago. the topic is
"microblaze firmware + UART handshaking blues"

I have modifed to make sure that the stack size is 0x1000. What else
could have gone wrong?

any help on this will be greatly appreciated.

thanks a million.
Chris

On 25 Feb., 01:16, chrisde...@gmail.com wrote:
you are not the only one having GCC/UART/EDK blues

1) with some GCC version it has been necessarry to add

call_some_really_dummy_do_nothing();

2) sometimes it is needed to add

wait_some_real_time();

at the start of main() or first UART output will not appear

3) if using EDK 9.1 then if the BRAM is made up of 2 or more
BRAM blocks then there is no tool error reported, but
the second BRAM does not get initialized with code, so if
the algorithm spans into second BRAM it will fail with
different behaviour depending on optimization setting

4) some other issues are also possible of course
5)
6)..

Antti Lukats