Memory access locking and unlocking ports in the same cycle allow more them 2 memory access per cycle (multiple ports are locked).

[agostini01]

I have been working in 4.2 and faced this issue. Which, after looking at Multi2Sim 5.0, I believe still persists.

Multiple memory port locks can happen on the same cycle (more them 2) because the locking and unlocking of ports does not take cycles to happen.

The issue happens due to the use of the function esim_engine->Next(frame) in Module.cc file. Next()'s int after and int period default to zero with its declaration in Engine.h

void Next(Event *event, int after = 0, int period = 0);

It would be great if someone could check if it persists in m2s 5.0. I run the simulation with: --mem-debug debug.mem

Than I looked at this file: cat debug.mem | grep -E "find and lock action" > find_and_lock_action.txt This file shows it is possible to have more then 2 find and lock action within the same cycle

2109000 291 0x200 si-gm find and lock action
2109000 299 0x300 si-gm find and lock action
2109000 307 0x400 si-gm find and lock action
2109000 315 0x500 si-gm find and lock action
2109000 323 0x600 si-gm find and lock action
2109000 331 0x700 si-gm find and lock action
2109000 268 0x85c0 si-gm find and lock action
2109000 472 0x800 si-gm find and lock action
2109000 480 0x900 si-gm find and lock action
2109000 488 0xa00 si-gm find and lock action
2109000 496 0xb00 si-gm find and lock action

As it is right now, I cannot run 5.0, to confirm it. I am not sure of the full implications but I believe changing: esim_engine->Next(frame) to esim_engine->Next(frame, 1) fixes the problem.

[agostini01]

The implication of this behavior is fewer cycles by the end of the simulation. In memory intensive applications this may really decrease the number of cycles for the simulation if compared to its real hardware counterpart.

[siscof]

Hi Agostini01, this issue is because in 5.0 is not checked that directory latency is 0. You could configure memory modules with DirectoryLatency = 1 from mem-config file for example . Although, you will see still a similar problem in "find_and_lock_event" when directory_entry is already locked, the issue will be solved for most acceses.

In m2s 4.2 by default directory_latency is 1 and it is checked that it is higher than 0 in src/mem_system/config.c. Do you simulate CPU or GPU?

"static struct mod_t mem_config_read_cache(struct config_t config, char *section){ ... if (dir_latency < 1) fatal("%s: cache %s: invalid value for variable " "'DirectoryLatency'.\n%s", mem_config_file_name, mod_name, mem_err_config_note); ..."

[agostini01]

Do you simulate CPU or GPU?

I was simulating GPU, Southern Island Architecture with 4.2.

You could configure memory modules with DirectoryLatency = 1 from mem-config file for example.

I will take a look at this next week.

Additionally, what Next() parameters configure? latency, dir_latency or other?

I have Latency assigned for global memory. Should I just assigned DirectoryLatency too?

; ---- Global memory
[Module si-gm]
Type = MainMemory
BlockSize = 64
Latency = 10 

[siscof]

Additionally, what Next() parameters configure? latency, dir_latency or other?

Next() send the frame to the next event with the lantency that you indicate. As you can see depending on the event one latency is used or another. For example in System::EventLoadHandler (previously mod_handler_nmoesi_load()) Next() is used without latencies because some event can be processed in the same cycle.

I have Latency assigned for global memory. Should I just assigned DirectoryLatency

you should, this way you ensure that your directoryLatency is x and avoid problems like you mentioned in the first comment. In fact, do this:

As it is right now, I cannot run 5.0, to confirm it. I am not sure of the full implications but I believe changing: esim_engine->Next(frame) to esim_engine->Next(frame, 1) fixes the problem.

it is the same that esim_engine->Next(frame, directoryLatency) configuring DirectoryLatency = 1;(for caches and main memory modules), and you will not need to program nothing.

[agostini01]

Thank you, this was really enlightening. I will adopt this method next time.