Re: [sv-bc] Weakly typed virtual interfaces?

 On 9/13/2010 9:38 AM, Gordon Vreugdenhil wrote:
> Type compatible of course has yet to be clarified --
> equivalent? matching? Peter said "if the types and
> names of all modport items match" so I assume he had
> the very strict rule in mind.
Without an explicit prototype, there would be no single declaration that could
claim to be definitive. I think even mundane things like indexing into an
array thus require that all aspects of the modport content layout must agree in
every detail. This allows each reference into the modport to be understood
accurately using any of the available declarations.

>
>
> However, I am still concerned with Peter's proposed
> directions. Since:
> Once a virtual interface has been initialized, all
> the components of the underlying interface instance are
> directly available to the virtual interface via the dot
> notation.
> Defining "compatibility" for a virtual interface assignment
> in terms of modports is not sufficient.
>
> *All* references to the underlying interfaces through the
> virtual interface reference must have the same level of
> compatibility.
>
> So this means that we'd really have to have a notion of
> weak type compatibility on *all* members of the virtual
> interface.
>
> But that means that if I had a class (or other strong type)
> defined within the interface and had elements of that type,
> I'd be breaking type rules in SV in general and causing all
> sorts of other issues.
>
>
> Peter has focused on the DUT side (port, etc) interactions
> but we have to watch the TB side too. We have to seriously
> consider all the very strange ways that people are *already*
> using interfaces and not break that either.
>
> The "weak typing" proposals (and variations thereof) seem
> to be workable for synthesis but I just don't see how it
> all hangs together for the TB side. I am also concerned
> about the existence of "strong types" within modport
> items; I'm not entirely clear on what that would look like
> nor what "weakening" means in such situations.
>
> Are we prepared to require that interfaces not define *any*
> new strong types? That would certainly reduce the problems,
> but could very easily break existing designs. Are we
> prepared to say that virtual interface references to/through
> strong types can only be made via types that are not defined
> within the underlying interfaces? Or are we going to end
> up having two sets of type rules -- a "weaker" set for
> modports and a "stronger" set for non-modport references?
> The latter might be very fragile.
>
>
> Along with Peter, I am willing to take some simulation time
> hit for having interface/virtual interface "weakening", but
> I am very worried about have *guarantees* that I don't need
> to rebuild type relationships (ie. re-elaborate any expression
> types, etc) when a virtual interface assignment occurs. Without
> substantive restrictions, I don't think I have that guarantee
> with any weakening of the system.
>
> Gord
>
>
> On 9/12/2010 6:09 AM, Peter Flake wrote:
>> Replying to Jonathan Bromley's message of Friday
>>
>> Given these two interfaces:
>>
>> interface IS;
>> reg signed [7:0] R;
>> modport M(inout R);
>> endinterface
>>
>> interface IU;
>> reg [7:0] R;
>> modport M(inout R);
>> endinterface
>>
>> The two modports are not compatible because they have R with different data types, one signed and one unsigned.
>>
>> function foo (interface.M VI);
>> ...
>> if (VI.R < 0) ...
>> endfunction
>>
>> The example here is analogous to a parameter of type "type" applied to R, which also changes the behaviour.
>>
>> However, I do not like the use of the generic "interface" here, and I am trying to get away from it with my weak typing proposal. By choosing IU or IS for the modport type in the header, the meaning
>> would be settled locally.
>>
>> Peter Flake
>>
>>

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