RE: supporting DPI in VHDL - possible scenarios for implementation

What I proposed was that we table discussions of Verilog 2001 and VHDL with
regard to SCEMI 2.0 until we complete the gist of the specification for
SystemVerilog.  If it turns out that time doesn't permit revisiting the
question before our deadline arrives, then it could possibly be a SCEMI 2.1
topic if the spec continues to evolve.
 
I don't think that we have any discussion or consensus regarding the means
that a completely SCEMI 2.0 (no mixed SCEMI 1.1) simulation will use to
deliver time to the "C" side from the HDL side. Since there are technologies
in play here that don't have to rely on a count of a fastest clock to give a
quantized time measurement, I think --- for starting the discussion --- that
we should begin with the requirement that every imported function call
should include some time information that the C side can use to resync its
global time variable. No more frequent time info exchange should be
required. In pure simulation mode, no such requirement is necessary -- the C
side can get time through vpi accesses.
 
russ

---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Shabtay
Matalon
Sent: Wednesday, October 12, 2005 3:14 PM
To: bojsen@zaiqtech.com; itc@eda.org
Subject: RE: supporting DPI in VHDL - possible scenarios for implementation



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

>