bluespec.com Forum Index bluespec.com
Bluespec Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

GetS and PutS(?)

 
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ...
View previous topic :: View next topic  
Author Message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Fri Oct 05, 2012 7:50 am    Post subject: GetS and PutS(?) Reply with quote

The GetS interface defined in the GetPut package has clear utility: i) Have abstract, non-destructive (split) Get-like capability; ii) expose only the first and deq methods, not other methods of an underlying (e.g. FIFO) implementation. Fine.

Was there some reason that its logical dual, PutS, was not defined as well? Along with a Connectable instance to mkConnect them?

It seems so obvious and simple that their absence makes me worry that there may be an issue we are not seeing.

Historically (pre GetS), we simply exposed the whole FIFO interface and relied upon the downstream Get-ing module to only invoke the first() and deq() methods.
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Fri Oct 05, 2012 12:20 pm    Post subject: Re: GetS and PutS(?) Reply with quote

PutS would just be Put -- the "put" method is just "enq" and doesn't get split apart the same way that "get" does. (If there's not a mkConnection instance for GetS and Put, then we should add it.)

Maybe you're thinking about a further variation, that exposes the ready signals? If you imagine that GetS could be named "FIFO_Out" (and Put is "FIFO_In"), then there is a further variation of interfaces called "FIFOF_Out" and "FIFOF_In":
Code:
interface FIFOF_Out#(type t);
   method Bool notEmpty();
   method t first();
   method Action deq();
endinterface

interface FIFOF_In#(type t);
   method Bool notFull();
   method Action enq(t);
endinterface

Many people define interfaces like these in their own projects -- in fact, I suspect that people don't actually use GetS, but define their own equivalent.

Bluespec would like to standardize this and add it to our library, but everyone has their own names for the interfaces and for the methods, and there hasn't been an agreement yet on what the standard interface should be. For instance, some people prefer the names "Import" and "Export", some people prefer names like "get" and "canGet" rather than the FIFO "deq" and "notEmpty" etc.

Actually, back to your original question, there is a type of Put that changes the protocol. I don't know what to call it (whether it's "PutS" or not), but it looks like this:
Code:
interface PutAck#(type t);
   method Action offer(t val);
   method Bool accepted();
endinterface

But I've only seen this used once. Usually, the FIFOF variations are what people want.
Back to top
View user's profile Send private message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Fri Oct 05, 2012 12:59 pm    Post subject: Reply with quote

Thanks Jacob!

That was the expository story I kind of expected (but needed) to hear. We have used an interface similar to what you described as PutAck, but called PutPeek instead. I prefer your naming. We will align our new code around PutAck's offer and accept methods.
Back to top
View user's profile Send private message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Wed Oct 24, 2012 9:41 am    Post subject: Reply with quote

Hi Jacob,

I'd like to continue this talk just a little further:

There is a common module interaction pattern we use where some producer module provides a GetS Interface, and some other consumer module it communicates with has a specific behavior:
a) It observes the first() of the GetS until there is a "new" element available
b) Internally, the consumer module takes exactly one of the "new" element, using some internal state to "take only one".
c) It acknowledges the element taken when it chooses to so (e.g. is ready for another)

(c) is the trouble because we sometimes try to "piggyback" some other meaning/purpose of "ack" as a direct consequence of the deq() action. So that (c) is not just "I'm ready for the next"; but its conjunction with some other condition.

BSV gives us a universe of options here. We're trying to be less ad hoc and standardize where it makes sense.

We would like something that still retains elastic-pipeline, point-to-point signalling. So an imagined mkConnect Instance could have temporal distance. I think your PutAck is bisectable; but our requirement of the piggyback meaning is, of course, usage specific.

You must have seen this pattern before. I suspect there is no free lunch.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ... All times are GMT - 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
bluespec.com topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP