Re: supporting DPI in VHDL - possible scenarios for implementation

Shabtay and ITC Techies,

I'm OK with tabling the discussion as long as we don't
drop consistent function call support for all three languages
from the SCE-MI 2.0 agenda.

Why not let VHDL benefit as well from the substantial ease of
use improvement of SCE-MI 2.0 over SCE-MI 1 ?

My view is that we're actually pretty close to deciding
common denominator data types so it really will not
be that much work to sew this up once we complete
the discussions on the other issues.

I think it is important to uphold the concensus reached in the June
meeting of SCE-MI 2.0 providing consistent support of a function
call interface in all 3 language domains.

The problem with doing it differently for different HDL languages
is that it will require inconsistent C interfaces as well.

I think we would be doing a disservice to the vendor, user,
and IP provider market place to release a standard that
is incomplete, i.e. solves SCE-MI 1.1 defficiencies in
one language but not the others.

Additionally all the support for pipes, streaming, and VLMs
would require inconsistent usage for different languages.

If we do our jobs right and create an interface that
uses a lowest common denominator set of types that all
three languages support, it will be easy to create
interchangeable HDL models that correctly couple with
common C models.

We have already proposed a baseline interface that shows how
consistent types and function call usage can be implemented
across the 3 languages. I don't see a lot of work left in
sewing this up in the specification.

It is certainly feasible to do it in the 2.0 timeframe.

As soon as we allow completely different looking interfaces
for different languages, we introduce a whole new set of
problems in terms of portability, adoption, enlarging market
pie, etc., which violates some of the high level principles
previously agreed to, and sends mixed messages to the
user base and make it very difficult to explain how the
standard supports multiple languages.

I also think it would be a mistake to drop the ball on VHDL
given its wide usage in the European market.

So I again, I would like to uphold the decisions we've already
made:

1. We have a function based interface that must be consistent
    for all three languages.

2. If, in addition, we adopt a new macro interface, we make
    it consistent for all three languages as well.

Most of the remaining issues to be discussed in the committee,
such as streaming and VLMs are language neutral anyway.
We can certainly make headway in this area by tabling the
multi-language discussion as suggested by Shabtay and Russ.

But given the concensus we've reached on this, dropping
it from the 2.0 agenda would, in my view, be a big
mistake.

-- johnS

Shabtay Matalon wrote:
> Hi Russ,
> 
>  
> 
> Please see my notes bellow.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> I suspect it was a mistake to try to resolve this issue at this time. 
> The other issues which are pertinent to the SystemVerilog case ought to
> 
> be tackled first, then we can come back to VHDL and Verilog2001. The 
> great technical advancement of SCEMI 2.0 is (using SystemVerilog) we can 
> achieve a testbench methodology truly portable from simulation to 
> emulation. We should solve remaining SystemVerilog issues without 
> distraction. Then, this optimal solution will help us figure out the 
> (necessarily) less optimal solution for the other simulators. 
> 
>  
> 
> What does the rest of the committee think? Is it time to table this 
> issue lest we spend the rest of the time available for technical 
> discussions on it? Perhaps given the time constraints, this is a SCEMI 
> 2.1 issue.
> 
> [Shabtay] I actually agree with you assessment. Great part of the 
> discussion and many of the emails going back and forth were trying to 
> “retrofit” the existing DPI-based proposal into Verilog 2001 and VHDL. I 
> think it will be a clean solution if we focus on resolving first the 
> remaining SystemVerilog issues in SCE-MI 2.0 and deal with any changes 
> to Verilog 1001 and VHDL after SCE-MI 2.0 gets approved and SCE-MI 2.1 
> gets discussed. We all agreed that SCE-MI 1.1 will be supported in 
> SCE-MI 2.0 and we have agreed to support a coexistence use model of 
> SCE-MI 1.1 macros in SCE-MI 2.0. Correct?
> 
>  
> 
> If all members agree to this, let’s pull all Verilog 2001 and VHDL 
> related proposals off the table. Each ITC member (now and in the future) 
> could bring any proposal they wish post SCE-MI 2.0 approval for SCE-MI 
> 2.1. What do you think?
> 
>  
> 
> We also have been holding on officially bringing our macro based 
> proposal now to the committee in spite of the fact that these macros 
> meet all principles stated across the three HDLs with the only exception 
> that these are not function-based on the HW side. We also stated our 
> support for SCE-MI 2.0 to be DPI-based standard for SystemVerilog. 
> 
>  
> 
> The one principle that they do not meet is the furtherance of  portable 
> IP written for both simulation and emulation. Also, if you say you support
> 
> SCEMI2.0 to be DPI-based for SystemVerilog, then why state that the 
> macros meet all principles for SystemVerilog (one of the 3 HDLs).?
> 
> [Shabtay] I hope that the above (if accepted) will put the Verilog 2001 
> and VHDL issue to bed for now. But from _a pure technical perspective_, 
> the macros based approach that Cadence has proposed in the past (not 
> SCE-MI 1.1 macros to be clear), does meet all principles including 
> supporting congruent use model with simulation. The only caveat is that 
> it is not function-based on the HW side (or DPI-based) as the committee 
> desires for SystemVerilog.
> 
>  
> 
> Thanks,
> 
>  
> 
> Shabtay
> 
>  
> 
>  
> 
> Cordially,
> 
> Russ
> 
> ---------------------------------------
> ---   Russ Vreeland (949)926-6143  ---
> ---    vreeland@broadcom.com <mailto:vreeland@broadcom.com>        ---
> ---    Senior Principal Engineer    ---
> ---    Broadcom Corporation         ---
> --------------------------------------- 
> 

-- 

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
________________________________________________________________