Hi Malek! Thanks a lot for all your answers I finally have solved my issue. What I have done is the following:
First of all add a global Time variable in my_InPort specific c++ class. During the execution of the L1requestToL2 InPort if the port processes a request. It also executes a my_InPort function which updates this Time variable with the current time. The isReady() function of my_InPort checks the Time variable, if the variable, has the value of the current_time it means that in this turn the L1requestToL2 InPort has processed something and nothing else can be processed. In this case the event is rescheduled for the next cycle. On the other side if the my_InPort is waked up before the L1requestToL2 InPort. The IsReady function in my_InPort c++ class, will check if the L1requestToL2 is scheduled to wake up in this cycle. If it is scheduled to wake up, in this cycle and it is ready to process a request during this cycle, my_InPort is not going to process any request, will update the Time variable to make sure that my_InPort does not process any request during this cycle, and will reschedule my_InPort to be executed in the next cycle. And that's all, now it is working fine. I hope anybody who wants to use this understand what I have done, otherwise if there is anything that is not clear, just ask me. Regards Martí 2012/2/23 Malek Musleh <[email protected]> > I should probably add that the Consumers of the Ports are initialized > in /mem/slicc/symbols/StateMachine.py > > You can do a search for: > > for port in self.in_ports: > expr = "%s" % (port.code) > * if expr.find("MYINPORT") >= 0: > code('${{port.code}}.setController(this);') > > # Set the queue consumers > code() > for port in self.in_ports: > code('${{port.code}}.setConsumer(this);') > > So when the L1requestToL2 port is being initialized you would pass in > a 2nd pointer to MYINPORT as well, so that whenever the L1requestToL2 > port wants to schedule an event, it can reschedule MYINPORT. > > You would just need to add something like * to determine when your > MYINPORT gets initialized. > > > Malek > > On Thu, Feb 23, 2012 at 9:47 AM, Malek Musleh <[email protected]> > wrote: > > 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 > -- 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
