Hi,
Thanks for your help. I have done following in the MESI Two Level code and
dma.sm and in dir.sm.
In DMA i have added the requester and requester Machine fields just like
MOESI CMP Dir.
out_msg.Requestor := machineID;
out_msg.RequestorMachine := MachineType:DMA;
and in directory I have made following changes to route the request to
proper DMA machine.
Following statements are used instead of just mapping address to DMA.
This is used inside the Send Data to DMA controller from directory action
and inside Send Data to DMA controller from directory from incoming PUTX
peek(requestNetwork_in, RequestMsg){
out_msg.Destination.add(map_Address_to_DMA(machineIDToNodeID(in_msg.Requestor)));
}
This is added inside the Send Ack to DMA controller. There are two separate
actions for sending ACK to DMA
one uses the TBE entry and other uses the in_msg.Requestor like above
statement.
if (is_valid(tbe)) {
out_msg.Destination.add(map_Address_to_DMA(machineIDToNodeID(tbe.Requestor)));
}
I have also made changes to type.py file in map_Address_to_DMA function.
MachineID
map_Address_to_DMA(NodeID id)
{
MachineID dma = {MachineType_DMA, id};
return dma;
}
I have added Node ID to function instead of address. Now with all these
changes the Data is delivered to the proper DMA but the Ack is still
delivered to the wrong DMA machine.
I have used the requester machine type and requester ID (Machine ID) in
above changes. Do I have to make any changes to how NetDest is generated?
or any other suggestions? Kindly, suggestions plz
best regards,
Muhammad
On 12 June 2017 at 13:10, Nikos Nikoleris <nikos.nikole...@arm.com> wrote:
> Hi Muhammad,
>
>
> If I remember correctly, MESI_Two_Level lacks support for multiple DMA
> controllers. The request message does not store the source of the packet
> and the response doesn't reach the right DMA controller. If you have a look
> at MOESI_CMP_directory, the DMA controller (MOESI_CMP_directory-dma.sm)
> encodes the source node in the Requestor and RequestorMachine fields which
> are then used to route the response. It shouldn't be too hard to add
> something similar for the MESI_Two_Level protocol.
>
>
> Nikos
> ------------------------------
> *From:* gem5-users <gem5-users-boun...@gem5.org> on behalf of SHARJEEL
> KHILJI <sharjeelsaeedkhi...@gmail.com>
> *Sent:* 12 June 2017 07:56:51
> *To:* gem5 users mailing list
> *Subject:* [gem5-users] Invalid transition DMA controller in NoC
>
> Hi,
>
> I am running the following system,
>
> scons build/ARM/gem5.debug PROTOCOL=MESI_Two_Level
>
> ./build/ARM/gem5.debug --debug-flags ProtocolTrace configs/example/fs.py
> --l1d_size=32kB --l1i_size=32kB --num-l2caches 4 --l2_size=1MB
> --cacheline_size=64 --machine-type=VExpress_GEM5_V1 --kernel
> /home/khilji/gem5/m5/system/binaries/vmlinux-aarch32 --disk-image
> /home/khilji/gem5/m5/system/disks/arm-ubuntu-natty-headless.img
> --dtb-filename /home/khilji/gem5/m5/system/dtb/armv7_gem5_v1_4cpu.dtb
> --num-cpus=4 --ruby --num-dirs=4 --network=garnet2.0 --topology Mesh_XY
> --mesh-rows 2 --mem-size 1GB --cpu-clock 1GHz
>
> While running this in debug, and booting the linux I get the following
> invalid DMA transition.
> When DMA controller receives the read request from the DMA sequencer it
> moves to the busy read state
> but when input response (Data) is received from (Directory/or PUTX L1) the
> DMA has already returned to
> ready state before Data event occurs. There are three DMA controllers
> (equal to dma ports) in the system as specified in config.ini.
> Is this because of the fact that one of the controllers issues the read
> request to directory and all of the controllers receive the response?
> and then those who have not issued the request receive the response while
> in ready state which results in exception.
> Following is the protocol trace
>
> 646885666000 2 L1Cache Load
> M>M [0xbda99a00, line 0xbda99a00]
> 646885667000 2 Seq Begin
> > [0x80359d7c, line 0x80359d40] IFETCH
> 646885668000 2 Seq Done
> > [0x80359d7c, line 0x80359d40] 1 cycles
> 646885668000 2 L1Cache Ifetch
> S>S [0x80359d40, line 0x80359d40]
> 646885670500 1 DMA ReadRequest
> READY>BUSY_RD [0xbf040000, line 0xbf040000]
> 646885676000 0 Directory DMA_READ M>M_DRD
> [0xbf040000, line 0xbf040000]
> 646885681500 0 L2Cache MEM_Inv MT>MT_I
> [0xbf040000, line 0xbf040000]
> 646885681500 0 L2Cache MEM_Inv MT_I>MT_I
> [0xbf040000, line 0xbf040000]
> 646885685500 2 L1Cache Inv
> M>I [0xbf040000, line 0xbf040000]
> 646885694000 0 L2Cache WB_Data MT_I>M_I
> [0xbf040000, line 0xbf040000]
> 646885700000 0 Directory Data
> M_DRD>M_DRDI [0xbf040000, line 0xbf040000]
>
> panic: Invalid transition
> system.ruby.dma_cntrl0 time: 1293771411 addr: 3204710400 event: Data
> state: READY
> Memory Usage: 1584496 KBytes
> Program aborted at tick 646885705500
>
> Any suggestions?
>
> best regards,
> Muhammad
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
