RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Shabtay,

> 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.

Yes, I understand that and of course did not mean to imply that either.
When I said drop VHDL and Verilog from SCE-MI 2.0, I obviously meant
to drop support for the new 2.0 features in those languages.

> 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.

I am not sure what you are trying to say here . . .  This sort of sounds
like circular reasoning along the lines of chicken and egg problems.
It sort sounds like you are arguing that there will not be enough
usage of function based interfaces to warrant spending time and effort
on standardizing them for SCE-MI 2.0.  But clearly there will be no
usage of such interfaces until there are implementations that support
them, so this does not sound like a valid argument against supporting
VHDL and Verilog.  I must be misunderstanding you.  Can you rephrase
or explain?

> 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.

It sounds like I need to again reinforce that this is *not* a proposal
but rather an illustration of a possible implementation.  Nobody is
required to do it that way so your dislike of it can not be used as
an argument against the function based interface proposals from John.

> I think it only reinforces the argument to focus on
> SystemVerilog first and incrementally add compatible solution for
> Verilog and VHDL.

Not really, since there *are* ways to implement the function based
interfaces that are not based on SCE-MI 1.1 infrastructure and
clock control.

> 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?

I believe it does.  It allows the same software side to drive
functionally equivalent representations of a transactor written
in each of the three languages.  This means an IP vendor can support
all three languages with the same software side and, furthermore,
the translation from one HDL language to the other will be pretty
straightforward, especially from SV to Verilog.

> 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.

Here we should clarify that you are talking about simulation, not
emulation.  Some form of clock control is still required in emulation
on most platforms.  Do you agree?

So the function based interface proposed by John does remove the clock
control the same way as DPI does it.  I stress again that you cannot
use my SCE-MI 1.1 based implementation sketch as a counter argument
here.  There are other possible implementations that do not use
SCE-MI 1.1 infrastructure and do not require clock control.

> 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.

I agree that the ability to view waveforms is important.  I do not
agree that it is not possible to get usable waveforms from a SCE-MI 1.1
based solution.

> 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?

No, I am restating what has been stated in the past: It is possible
to implement SCE-MI 1.x on a *standard* simulator and provide ways for
the user to look at waveforms such that times when the cclocks are
stopped appear as 0 time.

> 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.

Yes, but if they do they are using platform specific features beyond
the scope of SCE-MI.  Why should SCE-MI then care how simulation time
is reported and manipulated?

> So why drill on this option?

We went down this rat hole because you did not seem to appreciate that
the functional interface implementation sketch based on SCE-MI 1.1 was
just one of many possible implementations.

Per> Actually they do in part due to the backwards compatibility with
Per> SCE-MI 1.1.

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

Actually, it is not up to the user.  A compliant SCE-MI 2.0
implementation must implement all of SCE-MI 1.1 including the clock
control mechanisms regardless of whether or not the user uses any
SCE-MI 1.1 features.  However, the implementor has some choices.

> Can you show me how you use PLI for implementing export functions
> in Verilog 2001?

I can, but I am not sure it will help any as I expect you will find
something else wrong with such a solution.  I think we need to step
back for a while and look at what we are trying to accomplish here.

Per> This could entail adding ports to macro instances, adding extra
Per> signals to the user blocks that instantiate macros, threading these
Per> signals up and down the user's hierarchy, and adding one or more
Per> implementation specific blocks to the user's hierarchy.  Does this
Per> constitute regenerating the user's environment?

Shabtay> No it doesn’t. I think I explained that above.

Good, I think we made some progress here.  I wasn't sure you really
meant what you said in the previous email hence the request for
clarification.

So would you then accept a function based solution that replaces
imported and exported function calls with some infrastructure to
connect to the software side as not regenerating the user's
environment?

> Yes, if you build the environment such that you don’t expose any code
> regeneration to the user.

Ok, it seems you already answered the question above.

> 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?

I don't know about John, but you are asking a lot here.  It takes
quite a while to write this stuff down in a coherent manner.  I tried
once already and had my implementation sketch rejected on points
unrelated to your original issues.

Per> You did not really answer my question, so let me rephrase.  The
Per> function-based interface proposals you have seen so far fail to
Per> meet your principles.  Is it correct that the only principle they
Per> fail to meet is the `no code regeneration' principle?  If not, what
Per> other principles do they fail?

Shabtay> The example above with your SCE-MI 1.1 clock control based
Shabtay> proposal illustrates that you can work around one issue (avoid
Shabtay> code regeneration) and stumble on a different issue.

I was not talking about the implementation `proposal' but rather
John's proposal for function based interfaces in VHDL and Verilog.
So, is it correct that on an abstract level (not considering any
implementation proposal), only the `no core regeneration'
principle is not obviously satisfied?

> 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.

Before doing this I need to understand the level of detail you need
before such an illustration is acceptable to you.  In the meantime,
let's step back a bit.
 
> 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...

So, this is where I think we perhaps need to revisit the various
principles and see where the committee stands on each of them before
we proceed.

> 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.

Fine, but I'd still like to see a summary of the incremental updates
you have made or a planning to make.  This does not have to be more
than a text email listing the differences.  That should not take long
to write up.  You probably already have it in some form somewhere.
Just out of curiosity, are these changes in reaction to the Mentor
proposal, i.e., to make your proposal integrate more easily with
the Mentor proposal or are they changes based on feedback on your
original proposal?

> 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.

Well, if you don't, your macros will definitely not be in SCE-MI 2.0.

> All should remove Verilog and VHDL related content besides the
> interoperability models with SCE-MI 1.1.

No, we should not remove any such content from existing proposals.
What we are discussing is whether such content will end up in the
standard.  We should keep it as we will need it eventually even if
it does not make it to 2.0.

Per