[Mips32] CP0 m_ident becomes unstable

[xavier.guerin@…]

At some point in the simulation, the value of CP0 m_ident becomes completely erratic. In addition, due to the complexity of the code and my lack of experience in C++ debugging, I haven't been able to debug the problem. Important note: the behaviour is exactly the same using either SystemC or SystemCass.

Attached file: the output trace, the simulator files, and the application binary. Here is the command used to launch the simulator:

$ SIMULATION_N_CYCLES=1400000 SIMULATION_N_CPUS=4 ./simulation.x TC

[xavier.guerin@…]

Simulator

[xavier.guerin@…]

The Mips32 application

[xavier.guerin@…]

The trace

[xavier.guerin@…]

In addition to what has been explained:

1 - We are using our own coherent cache model, provided in the DMoC folder in the archive. 2 - The fix proposed in ticket #37 haven't been included yet, I modified mips32.cpp executeNCycles as follows:

211 #if 0 212 if ( m_exception != NO_EXCEPTION ) 213 goto got_exception; 214 #endif 215 216 if ( ncycle == 0 ) 217 goto early_end; 218 219 RUN_FOR(1); 220 221 if ( dreq_ok && ireq_ok ) { 222 #ifdef SOCLIB_MODULE_DEBUG 223 dump(); 224 #endif 225 if ( m_microcode_func ) { 226 (this->*m_microcode_func)(); 227 } else { 228 m_next_pc = r_npc; 229 m_jump_pc = r_npc+4; 230 m_resume_pc = r_pc; 231 run(); 232 } 233 if ( m_dreq.valid ) { 234 m_pc_for_dreq = r_pc; 235 m_pc_for_dreq_is_ds = m_next_pc != r_pc+4; 236 } 237 m_exec_cycles++; 238 } 239 else goto early_end;

If this in any case is the cause of the issue, please accept my apologies.

[xavier.guerin@…]

Mips32.cpp executeNCycles modification.

[Nicolas Pouillon]

I cant reproduce the bug described here.

Moreover, m_ident is a const field of Iss2​.

Being const means:

• No standard code can modify it
• Compiler could even warn about aliasing rules if someone casted a pointer on m_ident.

Therefore I think there is a piece of code going mad which overwrites random memory locations. Have you tried valgrind ? GDB watchpoints ?

With the elements we have for now, it can't be the Mips32 model on its own. Please investigate further.

[xavier.guerin@…]

It seems that the deep incompatibility between the way our cache and Mips32 work is causing this issue. I'm closing this ticket.