Re: SCEMI 2 handling of protected transactors

Shabtay,

It seems to me that the issue here is avoiding symbol clash which
is a general issue with C libraries. Traditionally this has been
handled using schemes with prefixes in identifiers to avoid
pollution of name spaces.

Perhaps it would make sense to provide IP vendor guidelines how
how this could be done with DPI based IP.

If public IP interfaces to vendor IP (say proxy libraries) are C++
this can be largely alleviated using C++ class encapsulation and/or
namespaces. In such cases the underlying ANSI C DPI communication
calls could have a vendor prefix such as, CadenceIpPortId().

You can be sure Mentor or Zaiq would not choose that name for
their PordId() calls ! :-)

Then, you can have a proxy class,

    class CadenceIpModelX {
      public:
        int PortId(){
           svSetScope( hdlContext );
           return CadenceIpPortId(); // Concealed DPI function call
        }
    };

that confines PordId() to be within the CadenceIpModelX class.
The user need only be concerned with using CadenceIpModelX::PortId().

Or, you could even have class IpModelX be part of an overall
Cadence IP namespace enclosing a family of IpModel interface
classes:

namespace CadenceIpSpace {

    class IpModelX
      public:
        int PortId(){ ... }
    };

    class IpModelY
      public:
        int PortId(){ ... }
    };
};

In this case, by declaring,

using namespace CadenceIpSpace;

The user need only be concerned with using IpModelX::PortId()
or IpModelY::PortId().

All of these approaches would avoid symbol clash.

BTW, as a side note, the last example hints that DPI does
fundamentally allow use of a single ANSI C identifier for
different model types - so long as no overloading is done
- ie. the ANSI C arg profile must be identical in all uses
of the symbol.

For example suppose all your models used the same convention
for returning the port ID via a DPI call to CadenceIpPortId().
There's no reason that different model types cannot reuse
the same function. This has proven to be quite a useful
feature in fact with DPI. I.e. you can implement "virtual
functions" of sorts in both directions between C and HDL.

-- johnS

Shabtay Matalon wrote:
> John, other ITC techies,
> 
>  
> 
> My question relates to DPI and not to the pipes this time…
> 
>  
> 
> Assume a scenario that an environment contains 2 transactors A and B 
> modeled independently by VIP providers A and B. Both A and B modelers 
> defined in their BFM an import function and use the same C identifier or 
> function name (by accident), lets say PortID. The C side now contains 
> two dynamic libraries for the proxy models with different implementation 
> of PortID. How would the end user (that cannot touch the C side code and 
> the BFM code – assume protected) deal with this scenario when 
> instantiating the two transactors in his/her environment?
> 
>  
> 
> Thanks,
> 
>  
> 
> Shabtay
> 
>  
> 
> -------------------------------------
> 
>  
> 
> Shabtay Matalon
> 
> Solution Architect
> 
> R&D, CVA
> 
> Phone: (408) 428 5081
> 
> email: shabtay@cadence.com
> 
>  
> 

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________