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 

Extending TieOff

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



Joined: 20 Nov 2011
Posts: 4

PostPosted: Mon Oct 17, 2016 10:00 am    Post subject: Extending TieOff Reply with quote

I would like to extend the existing TieOff typeclass to take in an extra
parameter, such that I can do TieOff on a Vector, AND in the printed
message, it prints the index of the vector.

Use case is if I have a vector of output ports I wanted to tie off,
I would like to know which ports is actually outputting.

What is the best way to do this? Should I copy TieOff.bsv from bsc and
put it in my project? Do I need to rename the modified library to avoid
the duplicated file warning message from bsc?

------- EDIT, Adding code example ---------
Code:

interface MyIfc #(numeric type n);
   interface Vector#(n, Get#(DataTypeT)) ports;
endinterface

mapM_(mkTieOff, module.ports);


Last edited by hwang on Mon Oct 17, 2016 7:48 pm; edited 1 time in total
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 494

PostPosted: Mon Oct 17, 2016 3:29 pm    Post subject: Re: Extending TieOff Reply with quote

What is the type of the interface that you want to tie off? You say "ports", but you're not referring to a Verilog output port, right?

And do you really mean "TieOff"? or do you mean "Connectable"? In either case, the answer is likely the same.

Also, the TieOff typeclass is just a naming convenience. You could define your own function for each interface that you want to tie off: mkTieOffPCIE, mkTieOffMemoryClient, mkTieOffNetworkNode, etc. By declaring a TieOff typeclass, we allow the name "mkTieOff" to be overloaded for all of those uses. When the compiler encounters the name "mkTieOff", it takes the type of the interface that you are applying "mkTieOff" to and chooses the appropriate definition for that type.

If you don't need that abstraction, then you don't have to use TieOff. (Personally, I don't use it.)

I didn't understand exactly what you wanted to do with the ports -- you want to tie them off, but you still want to display some information about what the tied off interface is doing? -- but if you're only doing this in one place, then you can just express that in the module that you're writing. If it's something that you want to do in multiple places, then you can make your own function, named appropriately.

If you're doing this in many places, with many types of interfaces, and what you're trying to implement is a global methodology for how tying off of interfaces should work -- for example, if you want every tie off to include a $display of the interface information -- then perhaps you'll want to define your own typeclass (with, for example, a string parameter containing an ID to use in the message). In that case, yes, you should probably declare an entirely new typeclass for yourself, with a new name -- to avoid clashing with TieOff from the library. (However, if you don't import TieOff and you don't import any library packages that use TieOff, then there won't be a clash, but I'd use a different name to be safe.)

One thing to notice, too, is that typeclass definitions can be overlapping. The library defines "mkTieOff" for "Vector#(n,t)", for any interface "t", and the implementation is to just call "mkTieOff" n-times on each element. However, if you want to do something special for a Vector of your own type "MyIfc", then you could write a typeclass definition for "Vector#(n,MyIfc)". The general definition (for type "t") will get used for other types, but your definition will be used for vectors of "MyIfc" type, because when BSC is resolving the overloaded name "mkTieOff", it will pick the definition that is most specific to the type. So it will pick "Vector#(n,MyIfc)" over "Vector#(n,t)".
Back to top
View user's profile Send private message
hwang



Joined: 20 Nov 2011
Posts: 4

PostPosted: Mon Oct 17, 2016 7:54 pm    Post subject: Reply with quote

Hi Julie,

Thanks for the elaborate answer.

I have updated the original question with a code example to give more context.

I will roll my own custom TieOff typeclass as suggested.

Thanks,
Han
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 494

PostPosted: Mon Oct 17, 2016 9:54 pm    Post subject: Reply with quote

Did you have to define an instance of TieOff for Get? I don't see an instance that's pre-defined in the library. The TieOff package shows an example of using it for Get, in a comment, but doesn't actually define an instance.

In fact, the example that's shown is illustrating a sink, not a tie off -- in my opinion. To me, TieOff means to do nothing, to not call any methods. In my mind, a TieOff interface for Get would never take data (and would be unnecessary).

If what you want is something that drains data, then I would suggest using a different typeclass, and calling it Sink (for example).
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