Hi Theo,
There are a number of poorly documented "rules" to writing SLICC protocols.
One rule is that you should not do *anything* other than trigger a
transition (call trigger(<Event>)) in a in_port. This sounds like the
underlying problem that you ran into.
Another rule that isn't documented is that the only place you should use a
'if' statement is in in_ports. You should never use an 'if' (to take two
different actions) in an 'action' block.
The reason for these two rules is that before a transition is triggered
(and its actions happen) Ruby checks all of the actions, etc. to make sure
that the resources required are available. If they're not, then a "protocol
stall" or a "resource stall" is returned instead of success by the
"in_port". If you bypass these mechanisms, strange things happen :).
Hopefully this makes it a bit more clear. Great questions, BTW!
Cheers,
Jason
On Sat, Jul 4, 2020 at 5:00 AM tolausso--- via gem5-users <
gem5-users@gem5.org> wrote:
> Hi Jason,
>
> Thank you for your very helpful (and prompt) reply!
>
> You were right that the SC_Failed was a red herring.
> After playing around with my protocol a bit more, the issue seems to have
> been that I was making the callback for load and store hits (e.g.
> `sequencer.{x}Callback(address, entry, false)`) directly in the
> mandatoryQueue_in definition, rather than by invoking a transition which
> then made the callback -- it appears this makes the callback silently fail.
> What's a bit strange is that callbacks for external hits (e.g.
> `sequencer.{x}(address, entry, true, {data-source})`) seem to work just
> fine when you declare them directly in an in_port rather than as part of an
> invoked transition... Not sure if this is either because the mandatoryQueue
> is a bit special, or if its because of the "initial access was a miss" flag.
>
> Thank you once again for taking the time to help out a less experienced
> fisherman :)
>
> Best,
> Theo
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
