07-13-2020 01:13 AM
I found that using VIVADO to associate the bit file with the elf file is different from the experimental result of downloading the bit file first and then loading the elf file through SDK debugging.
My design here is a network design based on Microblaze (including MIG control unit for DDR4, Ethernet, serial port, etc.). Please refer to the attached diagram for the design schematic.
First of all, if you download the original bit file first, and then load the elf file through the debug method in the SDK, the initialization of the network can be completed normally and subsequent work can be carried out.
Then, link the .elf file with the original bit to generate a new bit file, and find that it will be stuck halfway every time the network is initialized (as shown in the figure, after many tests, it is found that it is stuck in the self-negotiation link)
After VIVADO associates the elf file, the prompt message shows that the association is successful, and no error is reported.
I want to know, how to configure the FPGA directly through the bit file associated with the elf file, which is different from the SDK debugging mode? Why is there such a difference? And in my design, how can I ensure the normal operation while curing the elf program?
07-22-2020 03:12 PM
Comparing the Vivado log information with the Memdata messaging to the SDK log where the debugger calls updatemem would be helpful for understanding what is happening. Are these available?