Re: [sv-bc] Interface and modport Mantis items

Hello Peter, Gord:
   Regarding your weak type-checking proposal in (C), may I suggest that
we consider the package-based modport idea which Jonathan Bromley has
often advocated. I believe it serves the same intent as yours, and can
also alleviate Gord's 'interpretive' semantics concerns.
   I share Gord's concerns about the run-time nature of the type-
checking. It is not nice to have such a failure in a long running
simulation.

   In
    http://www.eda-stds.org/sv-bc/hm/10525.html,
it was suggested that both proposals are in alignment. Isn't it that
the symbol table that Peter speaks of as an implementation suggestion
is embodied as a package-based modport, with the user doing the work
to define it. Thus, this should solve the same problems as Peter's
proposal (C), including the virtual interface one ???

   To summerise, I'd like to propose allowing the modport construct not
only in interface scopes, but also in packages. The package-based
modport is used mainly for assisting RTL design, as opposed to the
access control function often associated with interface-based modports.
   A designer could then use a package-based modport in a module port
list, along-side the standard input/output/inout declarations. A
verification usage to connect a class-based object to a design is
not out of the question, using the virtual mechanism we have today.
   If it would simplify things, package-based modports can be restricted
to contain only 'modport_simple_ports_declaration', excluding
import/exports and clocking blocks.

   For example,
     package my_pkg;
       modport mp_axi_wr_addr_initiator (
          output [3:0] AWID, output [31:0] AWADDR, ... ,
          input AWREADY);
       modport mp_axi_wr_addr_target (
          input [3:0] AWID, input [31:0] AWADDR, ... ,
          output AWREADY);
       modport mp_axi_wr_data_initiator#(parameter dwidth=32) (
          output [3:0] WID, output [dwidth-1:0] WDATA, ... ,
          input WREADY);
       modport mp_axi_wr_data_target#(parameter dwidth=32) (
          input [3:0] WID, input [dwidth-1:0] WDATA, ... ,
          output WREADY);
     endpackage

     module axi_master (
         input clk, reset_n,
         my_pkg::mp_axi_wr_addr_initiator axi_wr_addr,
         my_pkg::mp_axi_wr_data_initiator#(64) axi_wr_data
     );

   The parameter in mp_axi_wr_data* is a variation on your proposal (A).
Note the similarity of this to using structs defined in a package on
the module port list. The only difference is that with package-based
modports, we now have directions.

   One can see that an implementation can unpack the contents
of the package-based modport alongside the other regular ports.
Synthesis tools probably already do this, and my hope is that this
would not be difficult to implement for other tools. Several
companies I have previously worked at successfully implemented similar
schemes (they called them port bundles), and used pre-processing scripts
to expand the port bundles into plain verilog.

The package-based modport represents an encapsulation of port names and
directions which can be reused, and referred to by a testbench through
the current virtual mechanism. Instead of virtual interfaces, we would
have virtual (fully-specialized) modports to which a testbench can
dynamically connect to. The simple use cases (a la VERA interfaces)
seem to be covered, but since I am neither a fan nor power-user of
virtual interfaces, I cannot comment further. A problem today is that
users are not obliged to use modports with their interfaces. With
package-based modports, they are.

   The message to users here would be that the current virtual interface
mechanism is broken, and there is little/no headroom to make changes
to the LRM which would not break somebody's legacy code. We leave it
as it is and introduce virtual package-based modports, which is
philosophically not radically different. Users who are happy with the
limitations of the current mechanism do nothing. The ones who are not
can be encouraged to move to virtual package-based modports.

   Provided the rough ideas described here pass the smell test, I am
more than happy to prepare a more detailed document/presentation which
can be presented at the next meeting.

regards,
kaiming

Peter Flake schrieb:
> Gordon,
>
>
>
> I understand your reservations. I just do not see how virtual
> interfaces work properly without more “interpretive” semantics, like
> Vera. The notion of a module type is much weaker than that of a data
> type because of defparams, configurations, binds etc., and I would apply
> this to interfaces too. If you could work out which interface instances
> were likely to be assigned to a virtual interface you could do the type
> checking at elaboration time, as you do now. Maybe another mechanism,
> such as configurations or attributes, could be used to combine
> flexibility with elaboration type checking.
>
>
>
> Peter.
>
>
>
> *From:* Gordon Vreugdenhil [mailto:gordonv@model.com]
> *Sent:* 25 October 2010 16:48
> *To:* Peter Flake
> *Cc:* sv-bc@eda.org
> *Subject:* Re: [sv-bc] Interface and modport Mantis items
>
>
>
> Peter,
>
> My biggest concern on (C) is tied to philosophical issues and "slippery
> slope" concerns. Your suggestion on weak typing pokes a huge hole in
> the assumption that type checking is done by the end of elaboration
> (with the exception of some OO related casting issues that are
> explicit). With the suggested approach, there now becomes a very
> complex run-time type check that could fail at very inopportune times.
> Imagine, for example, a multi-week simulation that fails with such an error.
>
> The slippery slope concern lies in how far we want to go with more
> "interpretive" semantics in SV. For example, a whole bunch of pending
> discussion regarding AOP models and possibly other things becomes
> "simple" if you are prepared to embed an interpretive model for some
> parts of the HDL behavior. But we've tried very hard to avoid going
> that direction due to concerns about long-term scalability and performance.
>
> So I'm concerned about opening this door and if we do so, I think there
> needs to be very careful consideration of the precedent and long-term
> directions in which we're heading. It isn't clear to me how to have
> that discussion in an effective manner.
>
> Gord.
>

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