Hello,
I did not base my protocol on any of the default protocols. I am guessing the
best way to solve this problem is to create a script or something that tracks
the proper value of each datablock. If a cache receives a datablock that is not
equal to the proper value, then there is an error. Or I suppose that I can
print the value of the datablock when it enters and leaves a L1 Cache make sure
that they are equal manually.
Also, I am not using speculative messaging and I may use the rubytester as well.
Best regards,
Alex
________________________________
From: Malek Musleh <[email protected]>
To: Alex Tomala <[email protected]>; gem5 users mailing list
<[email protected]>
Sent: Tuesday, January 28, 2014 2:02:35 PM
Subject: Re: [gem5-users] Verifying data integrity in a Ruby Network
Alex,
1)
If you based your custom protocol on one of the default (already provided)
protocols, then you can do a diff between the ProtocolTrace Flags to see where
things diverge. That way, you can isolate which new cache states/actions are
being triggered.
2) If your implementing any sort of speculative messaging in your protocol, it
would be wise to disable (not do said speculation) for supervisor packets.
There is some function called TheISA::inUserMode if I recall correctly, that
you can read and set as a new packet attribute when the packet is being
constructed (in the cpu.cc: buildReadPacket() or something like that).
I think I posted a patch some time ago on the reviewboard that does this.
3) You should probably debug your protocol using the rubytester to iron out as
many common case bugs as possible from the get go. Otherwise, a bug may not be
encountered when running benchmarks until the end of the program (at that point
you'd wait 5 days before the bug is triggered).
Malek
On Tue, Jan 28, 2014 at 12:50 PM, Alex Tomala <[email protected]> wrote:
Hello,
>
>
>I have been working a Ruby cache coherence protocol over the past few months.
>I have it completed and I am just debugging it now. I am trying to boot the
>Linux Kernel in a 16-core Alpha system. The problem I am having is the 15th
>and 16th CPU cores are not initializing. I noticed in the tracing debug output
>that the CPUs seem to continually fetch the same memory address afterwards
>(0x15e40). The system never reaches a deadlock as all of the memory requests
>are completed.
>
>
>I am guessing that the problem is that the data is lost when it is going from
>one L1Cache to another through the memory system. I am assuming that my cache
>coherence algorithms may accidentally write a incorrect data black into the
>cache memory instead of the proper one. In order to check if this is a
>problem, I need to somehow check if the L1 Cache is getting the correct data.
>I am wondering if anybody here has any suggestions how I can do it.
>
>
>Best regards,
>
>
>Alex
>_______________________________________________
>gem5-users mailing list
>[email protected]
>http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users