John, Over the last several months we have attempted to explore any viable avenue to support function-based API for Verilog and VHDL based on your proposal. I have asked you several times to illustrate how your proposal could be implemented using standard simulators Verilog and VHDL simulators meeting basic principles that customers are looking for. Since June we have not come close a bit in solving this issue as you have not presented any viable solution for the important simulation use model. At this point of time, I think that the only option is to focus on SystemVerilog first. Let's build on the consensus that we have reached so far which is quite significant. I can only hope that you will support the proposal made by Russ (that I endorsed today), no strings attached. Thanks, Shabtay >-----Original Message----- >From: John Stickley [mailto:John_Stickley@mentor.com] >Sent: Wednesday, October 12, 2005 5:34 PM >To: Shabtay Matalon >Cc: vreeland@broadcom.com; itc@eda.org >Subject: 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 >________________________________________________________________Received on Tue Oct 25 18:15:11 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 25 2005 - 18:15:23 PDT