Comments inline.
On Feb 24, 2011, at 7:26 AM, Jiho Ray Choi wrote:
Hello,
I am new to GEMS, and I got some questions while writing a new
protocol.
I looked at sample protocols and found out that there are mainly
five different behaviors of transitions.
1. First, there is a transition which invokes a set of actions and
dequeues the message which may trigger the event. I think it is a
typical case.
2. There is a transition which only dequeues the message. It means
that the message can be safely ignored at the state.
3. There is a transition which recycles the message. I think it is
when it's waiting for a certain event at the transient state. In
other words, the message should not be ignored but it should be
handled at the other state, and it is okay to serve other messages
first.
4. There is a transition which does not dequeue or recycle. While
recycling allows other messages served first, in this case, it
stalls till the state is changed so that the message can be served.
For example, when L2 receives a GET message and the requested block
is not present and the L2 cache is full, it triggers an event to
replace one of existing blocks. In this case, the transition
triggered by the event will not dequeue or recycle the GET message.
Then, it stalls until it receives the data from the memory, changes
its state to SHARED, and serves the GET message sitting at the head
of the queue.
5. Lastly, for some events, a transition is not specified. It's
because the writer is sure that those events are never triggered at
some states. However, in this case, I think it's safer to dequeue
the triggering message.
But such transitions are often a sign of underlying protocol bugs, in
which case you'd want to know such occurrings. Upon trying to make an
unspecified transition, ruby will halt immediately and output helpful
messages.
I'm sure you already know this but slicc also creates html outputs for
each protocol, which are immensely helpful in trying to understand
protocol behaviors. Just point your browser to ruby/html/<protocol>
Is my understanding correct? Am I missing any?
I am really not sure about the difference between the third and the
fourth.
Regarding the fourth behavior, how does it wake up in_port when it
is ready to serve the message? Does in_port periodically wake up if
not empty? If not, even if the GET message is luckily served thanks
to subsequent incoming messages, since (# of wake up) should be same
to (# of dequeue) without periodic wakeup, the last few messages
will remain unserved. So, I guess in_port wakes up not only by newly
arriving messages but also by some timer. Is it right?
Yes. I haven't checked this specific call chain, but just want to
mention that ruby does get woken up every SIMICS_RUBY_MULTIPLIER (or
OPAL_RUBY_MULTIPLIER if using opal) cycles. Search for
"runRubyEventQueue" (for ruby+simics) and
"OpalInterface::advanceTime" (for opal+ruby+simics).
Thank you for your supports.
Best regards,
Ray
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|