RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Shabtay,

> Sorry for my delayed response due to vacation and the need to do the
> usual email catch-up following that.

No problem!

Per>  a) If we do not have (1), IP developers that intend to support more
Per>     than one HDL including SystemVerilog would be forced to develop
Per>     and maintain at least two different software sides.

Shabtay> I don't think that this is a negative as you describe. It is
Shabtay> possible that variations could be addressed using localized
Shabtay> 'ifdef's sprinkled in few location in the SW side code

It is unlikely to be this simple because the macro-based API is
so different from the API-less DPI.  On one hand you have to write
Receive() and IsReady() callbacks, create SCE-MI port proxies,
create and read SCE-MI message objects, and call Send() to send
them; in DPI you just call your function passing the parameters
you like without having to convert anything to SCE-MI message
objects.  So the software sides will be quite differently
structured.

> The SW side API can be made very close or maybe could be unified.

I doubt it.  But that depends on how you define `very close', of
course.

> It is too early to tell due to the fluidly of the Mentor
> proposal in many areas at this time.

Well, there is no fluidity in regards to the software interface.
It is DPI.

Shabtay> My data is somewhat different. I think that it is yet to be
Shabtay> seen what IP vendors will prefer to choose.

I don't see any IP vendors outside of Zaiq doing SCE-MI 1.1
IP.  Perhaps Cadence and Mentor has some but I don't see any
IP vendor that is independent of the SCE-MI vendors doing it.
So I am sceptical that sticking with macro-based interfaces
in VHDL and non-SV Verilog will lead to any SCE-MI based IP
being offered from 3rd parties.

Shabtay> End users, if these are not IP developers, are quite shielded
Shabtay> from the interface used inside the transactors. I am not sure I
Shabtay> understand your point here.

End users of SCE-MI implementations that are not IP developers
but that also develop transactors.  This is quite common, of course.
They have different goals than IP developers but they still have
to write transactors.

Shabtay> the best solution I believe we should pursue at this time
Shabtay> is to work on SystemVerilog first, release this work in
Shabtay> SCE-MI 2.0 as soon as possible and evaluate how customers
Shabtay> would be receptive to it.

We have general consensus to focus on SystemVerilog in our
discussions at the meetings for now.  So far so good.

Shabtay> We should defer the issue of
Shabtay> functional API for Verilog and VHDL to SCE-MI 2.1 time
Shabtay> frame and bring the most viable solutions to the table at
Shabtay> that time.

This is still a point of contention.  The committee has not made
this decision yet and there is certainly not consensus on this
issue yet.  Your proposal essentially makes SCE-MI 2.0 a SystemVerilog
only standard and leaves Verilog and VHDL at SCE-MI 1.1.  Since this
is what Cadence wants, why don't you just choose not to implement
the proposed function based interface for Verilog and VHDL and
let the rest of us do it?

Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488