More TieOff instances?

[thoughtpolice]

The documentation for TieOff in the manual gives an example of usage by writing an instance for TieOff#(Get#(t)), but this instance doesn't actually exist. It actually is in the source code of the TieOff.bsv module, but only as a comment. Is there a reason for this?

The reason I ask is because I actually have a good use for it: I am trying to write an implementation of TileLink, and one of the properties that TileLink requires is that every request receives a response. In terms of Server#(a, b);, this means you always have to .response.get a b value for every call to .request.put(a) for some a.

For some use cases I only need to Put* into a channel, which responds with AccessAck, so I was thinking this is a perfect use of TieOff. For example:

module t#(...)(...);
  match { .server , .ifc } <- makeLightweightUncached();

  rule test;
    server.request.put(...);
  endrule

  mkTieOff(server.response);
endmodule

You could actually write it a bit differently too. What I wrote was the following using Probe to ensure the wire is preserved by the bluespec compiler (but can later be removed by synthesis.)

instance TieOff#(Get#(t))
    provisos ( Bits#(t, ts)
             );
  module mkTieOff(Get#(t) g, Empty ifc);
    let pr <- mkProbe;

    rule sink;
      t r <- g.get();
      pr <= r;
    endrule
  endmodule
endinstance

You could write similar instances for Server and Client too. There's actually an instance for MemoryClient in the Memory package already. Would these be worth adding upstream?

[czeck]

I doubt there can be a clear and obvious agreement on what defines a TieOff for common interface such as Get, Put, Client, etc. E.g. should TieOff#(Get#(a)) sink all data, or should it never be ready, or should it print an error message? In code I have written, I have desired all these versions and hence created custom modules (each a few line) to do exactly what is desired.

In my experience, I have created and used TieOff instances only for custom interfaces which require a methods to be always enabled. E.g., AXI-streams.