Re: [sv-bc] Task export in interface modports

Jonathan,

As with many things in interfaces, the LRM is not clear
about this relationship.

 From my perspective, it seems to pretty much defeat much
of the purpose of export routines for interfaces
if the definition is considered to be part of the
interface rather than a reference from an instance.
Having the routine "in" the interface would imply that an
interface with an export has one and only one behavior in
a complete system.  How can one then design modular
system components using a common interface framework?

The 24.7.4 (Draft 6) language likely leads to the inconsistency
here, along with the "definition by example" style of this
entire clause.  All of the examples involving and
discussing export use single instances of the interface.  Since
most of the text talks about "an interface" or similar in
places rather than "an interface instance", the confusion
isn't surprising.

I certainly agree with your expected result and that your
example is legal.  If you would remove the "I i_q();"
instance and use i_p in both connections, I would expect
and error in any interpretation since then you do have
a real conflict even at the instance level.

Gord.

jonathan.bromley@doulos.com wrote:
> I know this is way too late for the current PAR, and maybe 
> someone's already turned out all the lights at sv-bc, but 
> I'd appreciate any input on this issue where the LRM
> appears silent and existing implementations disagree.
> 
> Consider a module that exports a different task to 
> each of several ports of the same interface.modport type:
> 
> interface I();
>   modport mp(export task T());
>   initial begin
>     $display("interface %m calls T()");
>     T();
>   end
> endinterface : I
> //
> module M(I.mp p, I.mp q);
>   task p.T();
>     $display("called %m through p.T()");
>   endtask
>   task q.T();
>     $display("called %m through q.T()");
>   endtask
> endmodule : M
> //
> module top;
>   I i_p();
>   I i_q();
>   M m(i_p.mp, i_q.mp);
> endmodule : top
> 
> Is this legal?  Depending on your mental model of
> task export, you might think that each instance of
> interface I has some sort of reference to the exported 
> task, which itself resides within the module; or, 
> alternatively, you might imagine that the task is 
> effectively rewritten into the body of the interface.
> 
> If you take the former view (reference-to-task), as
> one simulator seems to do, then all is well.  Its 
> output from the code above is what I would hope for:
>   interface top.i_p calls T()
>   called top.m.p.T through p.T()
>   interface top.i_q calls T()
>   called top.m.q.T through q.T()
> 
> If you take the latter view (exported task is rewritten
> into the interface) then the code is illegal because
> it attempts to write two different tasks T() into
> the same interface.  I can see that this might be a
> reasonable interpretation if you think of the interface
> as having an "extern" task declaration; but, in that case,
> surely the task body should be named
>   interface_name::task_name
> rather than
>   port_name.task_name
> 
> Mysteriously, the simulator that complains about 
> this code will accept a slightly altered version
> in which the exporting module's ports are of 
> generic interface type:
> 
>   module M(interface.mp p, interface.mp q);
> 
> and it then gives the following output:
>   interface top.i_p calls T()
>   called top.m.T through p.T()
>   interface top.i_q calls T()
>   called top.m.T through q.T()
> 
> Note the different result from %m within the exported task.
> I can't make much sense of this.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> This is not just an academic exercise; there are real,
> useful scenarios in which I need to know what is correct.
> 
> Other things that might affect the answer, but don't
> seem to change anything in the two simulators I tried:
> - having the exported task be "automatic";
> - parameterizing the two interface instances differently.
> 
> Thanks in advance

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.