Subject: Re: [sv-ac] Informal proposal for #15 ref interface scope.
From: Surrendra Dudani (Surrendra.Dudani@synopsys.com)
Date: Mon Sep 08 2003 - 06:32:51 PDT
Hi Adam,
It seems to me that importing properties will work ok. But I'm not sure
about the assert statement. Two problems I see:
1) Importing is only done for definitions, not executable statements
2) If the assert statement is imported, then it will get triggered twice,
one for the interface, and another for modport.
Am I missing something?
Surrendra
At 02:57 PM 9/5/2003 -0500, you wrote:
>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"
>
**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752
Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
This archive was generated by hypermail 2b28 : Mon Sep 08 2003 - 06:33:36 PDT