Hi Marti,
In that case, you can simply deschedule/ and then reschedule the port.
Essentially what happens is that the consumers get scheduled on the
RubyEventQueue (/mem/ruby/eventqueue/RubyEventQueue.*)
So from an external C structure you can access the scheduled consumer
using the RubyQueue Ptr
g_eventQueue_ptr->
descheduleEventAbsolute(m_consumer_ptr,
(Time X);
where deschedule is a Function that I added (may not be part of the
latest repo?).
void
+RubyEventQueue::descheduleEventAbsolute(Consumer* consumer, Time timeAbs)
+{
+ assert(consumer != NULL);
+ if (consumer->alreadyScheduled(timeAbs)) {
+ assert(timeAbs > getTime());
+ consumer->removeScheduledWakeupTime(timeAbs);
+ }
+}
+
Then, you can subsequently call the Schedule Consumer Function:
g_eventQueue_ptr->scheduleEventAbsolute(m_consumer_ptr, ready_time);
Since it sounds like you might be needing to reschedule frequently,
you can just combine those 2 function calls into another function.
I don't think you can do it directly from the *.sm files, so you would
need to do it from an external C/C++ structure similar to TBE or
TimerTable (the latter being easier to replicate). Also you would need
to initialize the consumer ptrs to your port during the
constructor/init function.
Does that help?
Malek
2012/2/23 Martí Torrents Lapuerta <[email protected]>:
>
> Hi Malek,
>
> According to what I understand in the first solution you suggest the boolean
> is related to a cache entry, what this will force is that if both ports
> needs to access the same cache line, only one of them will be able to. What
> I want is that each cycle only one of the two ports issues a request.
>
> The second option seems to work better, the problem there is that if I
> schedule my_InPort in one cycle, where the L1RequestToL2 consumer is not
> scheduled, but later on, the L1RequestToL2 consumer is scheduled in a cycle
> where my_InPort is scheduled, both will be executed again in the same cycle.
> My question here would be: "In this situation it would be possible to
> reschedule my_InPort consumer to another cycle?" And how? :D If we find out
> that my issue would be totally solved!
>
> Thanks in advance!
>
>
> 2012/2/23 Malek Musleh <[email protected]>
>>
>> Hi Marti,
>>
>> I would think that you could use a boolean variable that you defined
>> in the CacheEntry/DirEntry Structure of the L2, and when set to false,
>> don't do the desired action.
>>
>> For example:
>>
>> inport(my_port, RequestMsg, latency="") {
>> peek(my_port, RequestMsg) {
>>
>> bool flag := getEntryFlag(cache_entry, address);
>>
>> if(flag) {
>>
>> trigger(Event: ........);
>>
>> }
>> // else do nothing
>> o
>> }
>> }
>>
>> The getEntryFlag Function could be something you define similar to the
>> isLocalOwnerValid Function.
>>
>> But in this case, the port is still scheduled and woken up every
>> cycle, but you just don't execute anything.
>>
>> If you truly don't want the port to be scheduled for wakeup, it is a
>> little more tricky. Essentially each in_port inherits from the
>> Consumer Class (/ruby/common/Consumer.hh)
>>
>> What you can do, is check to see if the L1RequestToL2 in_port
>> (consumer) is scheduled for some said cycle using
>> the bool alreadySchedule(Time) function, and if not, then schedule
>> your port (consumer) to wake up.
>>
>> Does that make sense?
>>
>> Malek
>>
>> 2012/2/22 Martí Torrents Lapuerta <[email protected]>:
>> > Hi Nilay!
>> >
>> > That seems a good point :D But how can I do that?
>> >
>> > Thanks!
>> >
>> >
>> > 2012/2/22 Nilay Vaish <[email protected]>
>> >>
>> >> Why can you not use a boolean variable to track whether or not the L1
>> >> cache sent a request to the L2 cache in this cycle?
>> >>
>> >> --
>> >> Nilay
>> >>
>> >>
>> >> On Wed, 22 Feb 2012, Martí Torrents Lapuerta wrote:
>> >>
>> >>> Hy Malek,
>> >>>
>> >>> Thanks for your answer, but I think that this parameter (rank) is only
>> >>> used
>> >>> when 2 inports are going to access the same address. In my case I want
>> >>> to
>> >>> issue only one of the two InPorts per cycle. Do you know any other
>> >>> way?
>> >>>
>> >>> Thanks for your attention.
>> >>>
>> >>> 2012/2/22 Malek Musleh <[email protected]>
>> >>>
>> >>>> Hi Marti,
>> >>>>
>> >>>> I believe you would need to specify the rank of the inport.
>> >>>>
>> >>>> For example:
>> >>>>
>> >>>> // Response Network
>> >>>> in_port(responseNetwork_in, ResponseMsg, responseToL1Cache, rank=2)
>> >>>> {
>> >>>>
>> >>>> You would then need to define the priority for each of the in_ports.
>> >>>>
>> >>>> Take a look at the MOESI_CMP_Token protocol as reference.
>> >>>>
>> >>>> Malek
>> >>>>
>> >>>> 2012/2/22 Martí Torrents Lapuerta <[email protected]>:
>> >>>>>
>> >>>>> Hello everybody,
>> >>>>>
>> >>>>> I am working with the MOESI_CMP_directory-L2cache protocol in Ruby.
>> >>>>> I
>> >>>>
>> >>>> have
>> >>>>>
>> >>>>> just added a new input port with some requests that I would like to
>> >>>>
>> >>>> inject
>> >>>>>
>> >>>>> in L2, however I only want to process this requests, when there is a
>> >>>>
>> >>>> cycle
>> >>>>>
>> >>>>> where the L1 is not sending any request to the L2. So myInPort must
>> >>>>> have
>> >>>>> less priority than the L1requestNetwork_in InPort. I do not know how
>> >>>>> to
>> >>>>
>> >>>> do
>> >>>>>
>> >>>>> this, Is there anybody who could help me with this issue?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Marti
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Martí Torrents Lapuerta
>> >>> [email protected]
>> >>> (+34)649 65 10 57
>> >>
>> >>
>> >> _______________________________________________
>> >> gem5-users mailing list
>> >> [email protected]
>> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >
>> >
>> >
>> >
>> > --
>> > Martí Torrents Lapuerta
>> > [email protected]
>> > (+34)649 65 10 57
>> >
>> > _______________________________________________
>> > 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
>
>
>
>
> --
> Martí Torrents Lapuerta
> [email protected]
> (+34)649 65 10 57
>
> _______________________________________________
> 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
