09-02-2019 06:05 AM
I am having some very unusual behaviour from the 64-bit Microblaze implementation when assigning a 64bit value to a u64 variable.
In Vivado 2019.1 I created a simple Microblaze design with the Microblaze configured in 64-bit. In SDK 2019.1 I then perform the following assignments as a test, with the corresponding results in the 'Variables' window.
Data_64 = 0xFFFF_FFFF_FFFF_FFFF; ('Variables' result : 0xFFFF_FFFF_FFFF_FFFF) - Correct
Data_64 = 0xFFFF_FFFF_FFFF_0000; ('Variables' result : 0xFFFF_FFFF_FFFF_0000) - Correct
Data_64 = 0xFFFF_FFFF_0000_FFFF; ('Variables' result : 0x0000_0000_0000_FFFF) - Error
Data_64 = 0xFFFF_0000_FFFF_FFFF; ('Variables' result : 0xFFFE_0000_FFFF_FFFF) - Error
Data_64 = 0x0000_FFFF_FFFF_FFFF; ('Variables' result : 0x0000_FFFE_FFFF_FFFF) - Error
Data_64 = 0x0000_0000_0000_0000; ('Variables' result : 0x0000_0000_0000_0000) - Correct
Data_64 = 0x0123_4567_89AB_CDEF; ('Variables' result : 0x0123_4566_89AB_CDEF) - Error
Data_64 = 0x0000_0004_0000_0000; ('Variables' result : 0x0000_0000_0000_0000) - Error
Clearly certain values are not being assigned correctly to the variable. If I use the same code for addressing I end up addressing sections of the program itself and obviously the program freezes. Especially for "0x0000_0004_0000_0000" which is the base address for my DDR4 memory interface.
Can anybody indicate what is the problem here and how I can resolve it?
05-16-2020 08:09 AM - edited 05-16-2020 08:10 AM
05-16-2020 09:10 AM
The next place to go digging is in the assembly. Consider using the -S option to the compiler in order to get a copy of the assembly language output. I'm not familiar with Microblaze assembly here, so I'm not sure how much I can help.
For reference, I think Xilinx's microblaze compiler is a derivative of GCC, so you should be able to chase any bugs there. If it isn't, then I am at least aware of a GCC backend for microblaze which you could use to your advantage. That should give you access to any and all of GCC's debugging capabilities, as well as the technical setup to how the compiler was configured.
06-05-2020 07:03 AM
I have encountered the same problem. Code for 64-bit Microblaze compiled by SDK 2019.1 on Windows does not work at all. This problem exists on Windows platform only. SDK 2019.1 on Linux (Ubuntu 20.04) generates correct code. I wrote a simple program with following commands:
... u32 * ptr; ptr = (u32*)0x0123456789abcdef; ptr = (u32*)0x200000000; ...
I compiled this program in SDK 2019.1 for Windows and Linux and compare disassembled code (left - Windows, right - Linux):
I can see that argument for imml instructions from code compiled in Windows is incorrect. In first case argument value is 16746923 (0xFF89AB) instead of 35243 (0x89AB). In second case argument value is 0 instead of 131072 (0x20000). Therefore I cannot assign a proper value to pointer and get access to 8GB of DDR3 memory in address space 0x200000000 - 0x3FFFFFFFF from Microblaze. By the way, Memory view of SDK Debug perspective displays content of DDR3 memory correctly. So it looks like there is some problem with compiler on Windows.
Compiler setting are the same on Windows and Linux. I used the same HDF file with bitstream for SDK on both platforms.
I tried to compile code on Vitis 2019.2 (Windows) and got even more broken result:
68 ptr = (u32*)0x0123456789abcdef; 0000000000001c3c: imml 16746923 0000000000001c40: addlik r3 , r0 , -12817 0000000000001c44: sli r3 , r19, 56 69 ptr = (u32*)0x200000000; 70 0000000000001c48: imml 0 0000000000001c4c: addlik r3 , r0 , 0 0000000000001c50: sli r3 , r19, 56
Currently it looks like using SDK on Linux is the only solution for 64-bit Microblaze.
If someone has positive experience with 64-bit Microblaze on Windows, please share your knowledge.