slicc: improved stalling support in protocols

Information
Submitter:	Tony Gutierrez
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 10840:3064139721f0
---------------------------
slicc: improved stalling support in protocols

Adds features to allow protocols to reschedule controllers when conditionally
stalling within inport logic or actions.  Also insures that resource and
protocol stalls are re-evaluated the next cycle.

Testing Done

Issue Summary

Description	From	Last Updated	Status
Why has this file been renamed?	Nilay Vaish	May 12, 2015, 9:35 a.m.	Open
This file was not renamed. It simply was created from the prior file using "hg cp".	Brad Beckmann	May 12, 2015, 12:30 p.m.	Open

src/mem/slicc/ast/CheckNextCycleAST.py (Diff revision 1)

Why has this file been renamed?

Show all issues

src/mem/slicc/ast/CheckNextCycleAST.py (Diff revision 1)

This file was not renamed. It simply was created from the prior file using "hg cp".

Show all issues

Nilay Vaish May 12, 2015, 12:37 p.m. (May 12, 2015, 12:37 p.m.)

I would suggest that we do not use hg cp since the two files do not have anything in common.

Brad Beckmann May 14, 2015, 10:32 a.m. (May 14, 2015, 10:32 a.m.)
```
Sure.  Done.
```

Similar to a couple of the other patches, it would be great if this SLICC change was documented on the wiki.
This adds a new builtin function to SLICC, right? Could you make this more explicit in the commit message? Something like "This adds the "void stallPort()" builtin function that can be called from the in_port logic or an action." Or whatever is appropriate.

Brad Beckmann May 12, 2015, 5:07 p.m. (May 12, 2015, 5:07 p.m.)

This is a pretty advanced feature. Actually one that I'd prefer most people not use. I'll update the commit message.

First, why do you need both stallPort() and check_next_cycle()?  Both are going to call scheduleEvent(Cycles(1)).

Second, why not just expose scheduleEvent() function and let the protocol author use it in whatever way they like.
Why add a new keyword for calling a function that simply calls another function?

Brad Beckmann May 14, 2015, 10:26 a.m. (May 14, 2015, 10:26 a.m.)

stallPort() is only meant to be used within an in_port, while check_next_cycle() is a pre-defined function that can be called within an action.  You are correct that this patch could just use check_next_cycle() and avoid introducing stallPort().  I preferred the stallPort() call within the in_port just to make it clear that the entire port is being stalled when stallPort() is called rather than triggering an event.

Nilay Vaish May 15, 2015, 8:04 a.m. (May 15, 2015, 8:04 a.m.)

stallPort() not actually stalling the port.  It is just calling scheduleEvent().
Is this not misleading?  Stalling should mean nothing would get processed
after the call to stallPort().

Secondly, why do we want to add these special cases?  Let's just expose scheduleEvent()
function through some .sm file and the protocol author can directly use it for whatever
purpose they want to.  Or else, you can add stallPort() and check_next_cycle() as functions in some .sm
file and use them in your protocols.  I think we are unnecessarily adding special
cases to the SLICC compiler.

Brad Beckmann May 19, 2015, 2:11 p.m. (May 19, 2015, 2:11 p.m.)

StallPort is in fact stalling the port by not dequeuing the message from the message buffer. Nothing eles on that port will be processed if one does dequeue the head pointer.

SLICC has not supported direct event queue manipulation. These APIs allow the experience SLICC programmer to manage message processing without calling the event queue APIs. You are absolutely right that these two functions generate the same code and could be replaced by adding the event queue APIs to the RubySlicc*.sm files.

It is simply a choice between the readability of SLICC protocols versus minimizing the SLICC API.

Description:

~		Changeset 10865:959f954b7dca
	~	Changeset 10840:3064139721f0

		slicc: improved stalling support in protocols

		Adds features to allow protocols to reschedule controllers when conditionally
		stalling within inport logic or actions. Also insures that resource and
		protocol stalls are re-evaluated the next cycle.

Diff:

Revision 2 (+56 -1)

Show changes

	src/mem/slicc/parser.py
	src/mem/slicc/ast/CheckNextCycleAST.py
	src/mem/slicc/ast/FuncCallExprAST.py
	src/mem/slicc/ast/InPortDeclAST.py
	src/mem/slicc/ast/__init__.py

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Description:

Changeset 10865:959f954b7dca

Changeset 10840:3064139721f0

Diff:

Status: Closed (submitted)