[sv-ac] Informal proposal for #15 ref interface scope.


Subject: [sv-ac] Informal proposal for #15 ref interface scope.
From: Adam Krolnik (krolnik@lsil.com)
Date: Fri Sep 05 2003 - 12:57:58 PDT


This is an initial proposal to allow reporting of error messages
from assertions from within the child scope of an interface.

Problem:

Assertion statements that are in an interface are a child of the scope
where the interface is instantiated. Modules that have ports connected
to the interface are the users of the interface though (driving or reading
the ports.)

E.g.

interface localbus; // Define the bus through an interface.
   ...

modport driver (input x, y, // Define a request for the bus.
                 output z ...

                );

...

// Define a property that must hold to properly use the bus.
A1: assert property (...) $error();

endinterface

// System level.
module parent(...);

// Here in the parent, we define this interface as b1.
// Here is where the assertion A1 is instantiated.
localbus b1;

// Connect the components to the same bus.
busdriver bd ( .localbus(b1), ... );
busreader br ( .localbus(b1), ...);

endmodule

module busdriver(
   localbus.driver localbus // This is the ports for the bus.
    ...

endmodule

Now, if the busdriver violates the assertion A1. It will report a message
something like:

Runtime ERROR: at time <> in parent.b1.A1 - assertion failure from file <>, line <>

This would direct an engineer to look at the scope, "parent.b1" to find the A1
assertion. It would be better to direct the engineer to the module that
caused the error (in this case the busdriver module.) I.e. the scope should be
parent.bd.A1 - the specific instance that is sending the error on the bus.

Proposal:

   The modport construct in addition to specifying port directions for
   signals of the interface also allows one to import or export tasks for
   use or definition. I propose that one be allowed to import an assertion
   or cover directive and have that assertion report the scope of where it
   is imported. E.g.

   Modify our example modport declaration to be:

     modport driver (input x, y, // Define a request for the bus.
                     output z ...,
                     import A1, // The driver will be the culprit if A1 fails.
                    );

   These assertions in the interface may be imported into multiple modport definitions.
   This allows for different sets of modports to be defined, separate from the actual
   usage of them.

I welcome any questions and commentary and will develop the complete proposal for the
Sept 15th deadline.

     Thanks.

      Adam Krolnik
      Verification Mgr.
      LSI Logic Corp.
      Plano TX. 75074
      Co-author "Assertion Based Design"



This archive was generated by hypermail 2b28 : Fri Sep 05 2003 - 12:58:38 PDT