RE: supporting DPI in VHDL - possible scenarios for implementation

From: Shabtay Matalon <shabtay_at_.....>
Date: Wed Oct 12 2005 - 15:13:33 PDT
Hi Per,

 

First, I (and I assume Russ) have not proposed that we drop Verilog and
VHDL in SCE-MI 2.0, but that we support it per the SCE-MI 1.1 use model.
I don't think that it is realistic to expect significant usage with
DPI-based SCE-MI 2.0 approach (given the current time frame proposed for
SCE-MI 2.0) to complete the standard on time and also and solidify a
Verilog and VHDL solution that meets the objectives that we set for
SCE-MI 2.0. Implementing a SCE-MI 2.0 interface along your proposal
below that maintains clock control and forces simulation to use cycle
stamp as the only mean to account for time, is not the type of solution
that will increase adoption of SCE-MI 2.0 based VIPs among simulation
users. I think it only reinforces the argument to focus on SystemVerilog
first and incrementally add compatible solution for Verilog and VHDL.

 

See my specific response embedded enclosed. Note that I am going on
vacation, so you won't hear from me until 10/20.

 

Regards,

 

Shabtay

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen

>Sent: Wednesday, October 12, 2005 12:02 AM

>To: itc@eda.org

>Subject: RE: supporting DPI in VHDL - possible scenarios for
implementation

> 

>Hi Shabtay,

> 

>> Your proposal is based on using clock control SCE-MI 1.1 in

>> simulation.

> 

>I showed you one possible implementation to answer you challenge

>to show an implementation that does not require modifying the

>simulator compiler.  Do you at least agree that implementing

>a function-based interface on top of SCE-MI 1.1 as outlined is

>possible without modifying the simulator compiler?  You do not

>have to like the solution to agree :-)

[Shabtay] This is not an issue whether I like the solution or not. Does
making the solution for Verilog and VHDL "DPI like" makes it compatible
with the SystemVerilog based solution?  If we want to do justice to the
Verilog and VHDL market with new SCE-MI 2.0 standard, let's either
remove clock control as in DPI, provide a solution that does not require
clock control (as per the Macro based approach we proposed) or use
SCE-MI 1.1 for a while until we come up with a good solution.  

 

The problem I see is that each solution that you or John proposed so far
for Verilog and VHDL came with its own set of issues resulting with
unacceptable solution for Verilog and VHDL simulation users.

> 

>> Such an implementation now forces us back into viewing time

>> progression on the HW side by only using cycle stamps.

> 

>Strictly speaking cycle stamp is the only concept of time that exists
in

>SCE-MI, so this is not a new issue.

[Shabtay] This was barely acceptable to emulation users and is not
acceptable to simulation users. 

> 

>> This imposes significant restrictions on the user.

> 

>I disagree about the restrictions being significant.  The whole purpose

>of SCE-MI is to provide a fast transport layer from a software-based

>verification environment into a simulation engine that in general will

>be some sort of hardware accelerated engine, but may also be a software

>simulator.  If you look at the whole range of engines out there, on
most

>of them only cycle stamping (counting clock cycles) makes sense as a
way

>to measure time.  SCE-MI users will be aware of this.  IP vendors that

>write portable models will be aware of this, because they should/will

>use the SCE-MI API only and there is no GetSimTime() call in SCE-MI.

>So the biggest problem really is that your waveforms may look funny

>depending on how the SCE-MI 1.1 subset is implemented.

[Shabtay] The waveform issue is a big issue given that debug is a
critical part of any solution. I am afraid that we'll have to disagree
on this if I failed to convince you so far.

> 

>It has been stated before that it is possible to implement SCE-MI 1.1
on

>software simulators in a way that takes care of this problem, i.e.,
that

>allows waveforms to be viewed such that periods where cclocks are

>stopped appear as zero simulation time.  This is the root of your

>problem with using SCE-MI 1.1 as a foundation for implementing a

>function-based interface, right?

[Shabtay] This issue applies to the approach that you have proposed
here. Are you suggesting that we modify our simulator or provide a patch
to simulation users?

> 

>> Any trace data and any system tasks that uses time will see a

>> different time from the one reported by cycle stamp.

> 

>I don't believe SCE-MI supports system tasks let alone system tasks

>that use time, so the real problem is how waveforms appear.

[Shabtay] SCE-MI neither supports nor precludes the use of time on the
HW side. Users can do what they want. For example, assertions firing on
the HW side can report time independently of SCEMI. I think we all
reached already the conclusion that we want to eliminate clock control
and different view of time moving forward. So why drill on this option?

> 

>> Practically, the simulation use model will be highly restrictive.

> 

>Actually, it will be no more restrictive than running on any emulator

>with SCE-MI.  So is this unacceptably restrictive?  Given that the

>goal of supporting SCE-MI on simulators is to allow development and

>debugging of SCE-MI-based environments that will run on emulators

>eventually, I don't think so.

[Shabtay] I'm afraid we disagree.

> 

>> Neither the macro based approach across all HDLs that Cadence
proposed

>> in the past nor the existing DPI based proposal for SystemVerilog

>> imposes such a restriction on the end user.

> 

>Actually they do in part due to the backwards compatibility with

>SCE-MI 1.1.

[Shabtay] That's a user's choice. If we provide a solution in the future
that does not rely on clock control, we leave it to the users to choose
which of the two use models they prefer to use.

> 

>>  Why would we impose it only on Verilog and VHDL users?

> 

>Well, do not forget that what we are talking about here is just one

>possible way of implementing the function-based interface in Verilog

>and VHDL.  There are other ways that do not use SCE-MI 1.1 clock

>control.  For instance, instead of replacing the function calls with

>SCE-MI 1.1 infrastructure you can replace it with some PLI-based

>infrastructure without any clock control mechanism.  Calls happen

>in zero time solely by virtue of having the simulator thread wait

>for the results from the software side.  I see now that it was a

>mistake to show you a SCE-MI 1.1-based solution; I had assumed that

>using SCE-MI 1.1 would be a nice basis due to it being well understood.

[Shabtay] Yes, it was a mistake. Can you show me how you use PLI for
implementing export functions in Verilog 2001?

> 

>Regardless, any vendor that wants to implement SCE-MI 2.0 on a

>simulator must address the SCE-MI 1.1 subset and hence deal with the

>clock control issues you talk about.  But that is an issue completely

>separate from whether a function-based interface has any merit on

>`old' Verilog and VHDL.  Do you agree?

[Shabtay] Yes.

> 

>> We need to distinguish between modifying user's source code and

>> mandating that users comply with a certain methodology. Independent
of

>> the API that is being used, users will have to build transactors,

>> define the hierarchies and make connections to certain API resources

>> in a certain way. Everything that you have described so far falls
into

>> the methodology of using the SCE-MI 1.1 API and none requires

>> regeneration of the user's environment.

> 

>I would agree with you but I bet that we would not be using the same

>definition of `regeneration of the user's environment', then.  For

>example, in VHDL to make a SCE-MI 1.1 environment simulatable you need

>to connect both user-visible SCE-MI 1.1 infrastructure as well as

>implementation specific infrastructure from the guts of the macros to

>whatever central block does the clock control, for instance.  This

>could entail adding ports to macro instances, adding extra signals to

>the user blocks that instantiate macros, threading these signals up

>and down the user's hierarchy, and adding one or more implementation

>specific blocks to the user's hierarchy.  Does this constitute

>regenerating the user's environment?

[Shabtay] No it doesn't. I think I explained that above. Users and
modelers need to understand an interface its requirements and how to use
it. Once they follow the guidelines, we should run their environments
with any libraries we wish w/o modifying the source code they use for
debugging.

> 

>> Different implementation can do different things. The macros "guts"

>> for example could be fully generated by the infrastructure linker or
a

>> parameterized library may be linked in.

> 

>This is of course irrelevant to what happens to the code that

>instantiates these macros.

[Shabtay] Correct. 

> 

>> The strongest reservation I have to modifying users' code is the

>> implication on debug. [...] It is not acceptable to modify their code

>> (even if we state that the modified code is equivalent) and ask users

>> to debug a modified code regenerated by our application. Do you still

>> think that this is acceptable to simulation users?

> 

>Oh, yes, I definitely disagree with you here.  Anyone who is used to

>C/C++ programming is familiar with this.  The code that the compiler

>sees is a pre-processed (or regenerated, if you will) version of

>the code the user wrote.  This is nothing new.  It is up to the

>implementation to make the impact on debug as small as possible.

[Shabtay] Yes, if you build the environment such that you don't expose
any code regeneration to the user. I asked your or John to show me an
implementation for Verilog on simulation that does all that. Instead of
just telling me what we should do, why won't you address to the my
original request and show me how you implement the flow on standard
Verilog 2001 simulator using PLI/VPI or whatever the simulator can
support? 

> 

>> But I have not seen yet a proposal for a functional bases API that
its

>> implementation meets these principles.

> 

>You did not really answer my question, so let me rephrase.  The

>function-based interface proposals you have seen so far fail to

>meet your principles.  Is it correct that the only principle they

>fail to meet is the `no code regeneration' principle?  If not, what

>other principles do they fail?

[Shabtay] The example above with your SCE-MI 1.1 clock control based
proposal illustrates that you can work around one issue (avoid code
regeneration) and stumble on a different issue. Let me suggest that you
illustrate the 'no code regeneration' with Verilog 2001 using PLI. I
listed the important principles we look at, but I can't guarantee it is
complete. We need to use common sense after all. 

> 

>I'd like to note that your `no code regeneration' principle has not

>been agreed upon by the committee.

[Shabtay] I'm sorry. We are committed to providing EDA tools and
solutions that are acceptable to our customers based on feedback that we
have received from customers over the years. I conveyed and explained
the reasons for the principles we adopted as a result of such feedback
and hope the committee will agree to these. If they will agree or not is
not in my control...

> 

>> Now, it is my understanding that you also support Russ idea to focus

>> on SystemVerilog for SCE-MI 2.0 and deal with Verilog and VHDL for

>> SCE-MI 2.1.

> 

>No, I do not agree with this as stated.  I do agree that we should

>probably focus on SystemVerilog for a while, but I do not agree that

>we should drop `old' Verilog and VHDL from 2.0.

[Shabtay] I addressed this above.

> 

>> Should we then stop discussing this at this point and focus on

>> SystemVerilog for SCE-MI 2.0?

> 

>No :-)  I'd like to see your macro proposal so I can evaluate your

>claim that it fulfills your principles by myself, for instance.

[Shabtay] While we will need to provide some incremental update to the
macro proposal that we proposed in the past, you already have seen most
of it on Accellera web. You are more than welcomed to assess what was
posted. I have yet to hear from others, but if Russ latest proposal is
agreed to (we stated we support it), there is no use in bringing any new
or updated Verilog and VHDL proposals to the table at this time. All
should remove Verilog and VHDL related content besides the
interoperability models with SCE-MI 1.1. 

> 

>Per

> 

 
Received on Wed Oct 12 15:13:53 2005

This archive was generated by hypermail 2.1.8 : Wed Oct 12 2005 - 15:14:27 PDT