Shabtay’s take 04/28 Our resolution to
this sticky issue is that Verilog 2001 and VHDL data types using DPI
import/export should be deprecated from the SCE-MI 2.0 spec. VHDL/Verilog HW
side will be supported using the SCEMI 1.1 use model and reconsidered in SCEMI
2.1.
Per disagrees with this position
Firming up what we are going to do for Verilog and VHDL both
relative to the
a) How will context be
handled in VHDL and 'vanilla' Verilog? The user should not have to call
SystemVerilog APIs to access context information in non-SystemVerilog use
models.
b)
Is current comment based pragma syntax attributing
scheme adequate for Verilog, VHDL ?
- Specifically for
VHDL should we explore using attributes instead?
John
has sent out a proposal (separate text file) for converting the pragmas to attributes. He believes that everything in there
is a pure part of the language that can be got from a compiler plus access
through a standard simulation mechanism such as PLI.
Russ>
While we should only define a C interface we should leave open the C++ bindings
for 1.1 Broadcom has had no issues about using DPI within C++.
Per> I think this should be clarified to say that
all new SCE-MI 2.0 features only get a C binding, but the old C++ binding for
SCE-MI 1.1 stays as it is by virtue of backwards compatibility.
VHDL,
Verilog do not have a function call export capability. We need to make sure
that something can work natively in all languages.
Macro's do not work natively in any language. Should be able to lay functional calls over macros or the other way
around.
Per>
The choice of HDL should be transparent to the
software side, i.e., the user should be able to use Verilog 2001,
SystemVerilog, and VHDL interchangeably without having to rewrite the software
side
Shabtay> Very important goal that should be
attempted, but one that cannot override the other principles.
Shabtay>
I didn't state that defining a function based interface in old Verilog/Verilog 2001
and/or VHDL is impossible. John's latest proposal doesn't meet the principles I
outlined. If there are other proposals that do, we should evaluate them.
Per>
As far as I could tell, the only reason you are rejecting John's proposal is
that according to Cadence's analysis there is no way to implement it in a
standard simulator without some degree of `code regeneration'. Is this correct?
Per>
I'd like to understand why Cadence sees code regeneration as such a big
problem? And why do you not have the exact
same issue in a macro based approach in SCE-MI 1.1 as well as 2.0? Certainly, this would be the case in strict
VHDL, wouldn't it? In strict VHDL you
can't add the SCE-MI 1.1 infrastructure without changing the code to some
degree. In Verilog you probably can get
by using cross-module references to some degree, but I suspect that even in
Verilog code must be added to actually implement the SCE-MI infrastructure. So I am wondering why Cadence sees code regeneration as a big
problem? Note, I am not saying
that it is actually required. I'd like
to hear John's response to your questions to him on that topic as well. But assuming the worst case, why is Cadence
opposed to implementing the infrastructure linker as a sort of preprocessor
that dumps out modified code that is then passed to the target?
JohnS>
As per an action item
requested of Duaine and me, the following presents possible scenarios for how
one might implement DPI over VHDL purely in a software simulator environment.
It does not describe scenarios
for synthesis of DPI based code to an emulator environment. However, for this
case, function calls can conceivably be replaced with synthesizeable
infrastructure layered over SCE-MI 1.1 macros where message input and output
ports are used to carry function input and output messages across the
communication link.
In the text below, imported
and exported 0-time functions are described separately.
Specifically VHDL is
described is it makes the case that DPI-like interfaces can be implemented over
a language that does not natively support DPI without requiring extensions to
the language itself. Rather, legal, compliant attributes are used to alert the
language compiler and/or SCE-MI infrastructure linker to generate extra
infrastructure to support the DPI call interface.
It is important to note that
this does not present any new requirements for SCE-MI that were not already
there for SCE-MI 1.1 macros in terms of infrastructure linker support. In fact,
in some cases it has proven to be easy to implement a function call based
interface since, on most industrial HDL software simulators, some capability
already exists for function call type interfaces - such as foreign functions in
VHDL and PLI user defined tasks in Verilog.
--------------------------------------------------------------
Imported 0-time functions
Imported functions can be
declared in VHDL as procedures and can be called from user clocked RTL
processes. Here is an example of a simple user application written in VHDL that
makes use of the proposed DPI imported function interface:
entity PipelineEgressTransactor
is port(
TokenOut: in std_logic_vector(127
downto 0);
Clock, Reset: in std_logic);
end PipelineEgressTransactor;
architecture DPI of PipelineEgressTransactor
is
--This is a
Imported Function declaration--
procedure UploadEgressTransaction(
signal countOut : in std_logic_vector
(31 downto 0)
signal dataOut : in std_logic_vector (63
downto 0);
signal statusOut : in std_logic_vector
(31 downto 0)) is
begin end
procedure;
attribute
foreign of UploadEgressTransaction:
procedure is
"sce_mi import DPI-C";
begin
process (Clock)
begin
if(Reset /=
'1' and IsStdLogicVectorZero(TokenOut)
= '0') then
UploadEgressTransaction(
TokenOut(31 downto 0),
TokenOut(95 downto 32),
TokenOut(127 downto 96));
end if;
end process;
end DPI;
There are a number of
scenarios in which an implementation can implement the "guts" of the
empty placeholder function, UploadEgressTransaction().
By no means do we try to
dictate any one of those ways here. We only want to suggest possibilities for
implementation. Different vendors would most likely choose different solutions
depending on what is optimal in their environment.
3 of those possibilities are
mentioned here:
1. The vendor can modify
their compiler so that the empty procedure is automatically replaced directly
with generated native code that hooks into an infrastructure implementation
that directly communicates to C using whatever VHDL foreign language interface
(FLI) that is supported by that vendor.
This foreign language
interfacing mechanism would look similar to the one that SCE-MI 1.1 macros
would have to use today.
Note: No source code
transformation is required with this approach as the extra infrastructure is
emitted directly into the native code output unit.
2. VHDL foreign functions - this
is similar to 1 above. If a vendor has created a mechanism in their simulator
to implement "foreign functions" as designated by the `FOREIGN
attribute as described in the LRM, this mechanism can be easily be leveraged to
implement imported DPI functions. In fact, a very good case can be made that
such an implementation could be relatively easy since this feature already
supports function calling semantics and most vendor have already have some sort
of support for foreign functions.
Using the `FOREIGN attribute
syntax shown in the example above (which is also consistent with LRM
recommended uses of this attribute to denote foreign functions), the vendor
could directly implement DPI imported functions as foreign functions using
their vendor specific mechanism that is already in place for foreign functions.
3. If the vendor simulator
is mixed language and already supports a SystemVerilog DPI interface, the
internals of the VHDL call could be a wrapper that directly calls a
SystemVerilog DPI imported call.
This option is similar to 2
except it utilizes existing DPI capability rather than existing foreign
function capability.
The modified internals for
the VHDL call could either be directly generated as native code (as described
in 1 above) or the user's source code could be slightly transformed to give the
empty placeholder function a body that calls the DPI function.
-------------------------------------------------------------------------
Exported 0-Time Functions
The SCE-MI 2 DPI proposal
states that 0-time procedures in VHDL can be attributed as exported DPI
functions and called from C.
Exported functions can
potentially do the following:
1. C->HDL message passing or config ops (input args)
2. C->HDL query ops (output args)
The exported function would
be a VHDL procedure that can do assignments of input formal argument values to
surrounding signals for passing input messages and can do assignments of
surrounding signal values to output formal arguments for passing output
messages.
To achieve this, an exported
function can be declared as a specially attributed procedure in the declarative
region of an architecture.
In the following user VHDL
application example, the exported function, 'ServiceIngressTransaction()'
assigns to signals 'serviceCallDetected', 'holdingCount', 'receivedCount', 'receivedData' and 'receivedStatus'
declared in the architecture scope.
-- the
following is a Exported Function definition--
procedure ServiceIngressTransaction
(
signal holdCountIn : in integer;
signal receivedCountIn : in std_logic_vector
(31 downto 0);
signal dataIn : in std_logic_vector (63 downto 0);
signal statusIn : in std_logic_vector
(31 downto 0)) is
begin
serviceCallDetected
<= '1';
holdingCount
<= holdCountIn;
receivedCount
<= receivedCountIn;
receivedData
<= dataIn;
receivedStatus
<= statusIn;
end procedure;
attribute foreign of ServiceIngressTransaction:
procedure is
"sce_mi export DPI-C";
process begin
wait until (Clock'event and Clock = '1');
if(serviceCallDetected = '1') then serviceCallDetected
<= '0';
if (Reset /= '1')
then
while holdingCount > 0 loop
holdingCount <= holdingCount
- 1;
wait
until (Clock'event and Clock = '1');
end loop;
TokenIn
<= receivedStatus & receivedData
& receivedCount;
wait until (Clock'event and Clock = '1');
TokenIn
<= (others => '0');
wait until (Clock'event and Clock = '1');
end if;
end process;
Here again are 3 possible
scenarios for implementing this exported function.
1. The vendor can modify
their compiler so that in addition to generating simulation code for the user's
architecture and procedure, it also generates an additional process block in
the same architecture scope. This process block communicates directly with the
C side using special synchronization signals together with whatever VHDL
foreign language interface (FLI) that is supported by that vendor.
The special process block
would wait until one of the synchronization signals indicates that a call to
the exported function was initiated. It would then take the input data
arguments passed along from the C side via the FLI and make a call to the
actual exported procedure defined by the user. The output arguments of the call
would be passed back to C side via the FLI.
It might look something like this:
-- Auxiliary process to manage calls to
exported
-- ServiceIngressTransaction() function
ServiceIngressTransaction_wrapper:
process
-- These variables updated via C
interface API
variable holdCountIn : integer;
variable receivedCountIn : std_logic_vector
(31 downto 0);
variable dataIn : std_logic_vector (63 downto 0);
variable statusIn : std_logic_vector (31 downto 0);
begin
-- Wait for signal triggered via PLI,
VHPI, FLI
-- or similar
C-API interface.
wait on ServiceIngressTransaction_trigger;
-- Make the actual call to the
exported function (args
-- are set in wrapper
ServiceIngressTransaction
(
holdCountIn, receivedCountIn,
dataIn, statusIn );
-- Toggle trigger to notify C side
(via value change callback)
-- that call
is complete.
ServiceIngressTransaction_trigger
<= ~ServiceIngressTransaction_trigger;
end process ServiceIngressTransaction_wrapper;
2. In a mixed language
simulator this process could be a Verilog process that is placed completely
outside the user's original source unit and makes the call to the exported
function using cross scope references. Using this approach would require
absolutely no source code transformation and it could be implemented with no
alterations to the vendor's compiler as well. Rather an extra module would be
created by the infrastructure linker containing the cross scoping wrapper
processes and could be compiled into its own separate database unit that is
elaborated along with the rest of the design.
3. If the vendor simulator
is mixed language and already supports a SystemVerilog DPI interface, an actual
DPI exported function can be added as a wrapper that then calls the VHDL
exported function.
Shabtay>
Response to John
While your email below
illustrates legitimate scenarios for how DPI could have been implemented by a
VHDL compiler, this does not show how an existing VHDL simulation compiler will
run your code example w/o being modified.
I conclude that your
proposal could only be implemented by modifying standard IEEE VHDL compilers or
by regenerating the code by the Infrastructure Linker such that that existing
VHDL compiler will read the modified code. I would also conclude by deduction
that the same assumptions apply to Verilog 2001. Do you agree with this
technical conclusion?
johnS>>
I strongly disagree. There
are two aspects to a compiler:
1. IEEE VHDL compliant
language analysis
2. Vendor specific native
code generation.
My approach does not change
1.
My approach suggests that
vendor specific code generation can be changed or that reasonable source
transformation can be performed.
Yes vendors will need to do
something to support SCE-MI 2. Just as they need to provide infrastructure
linker support for SCE-MI 1. We've never made claims to the contrary nor did the
original requirements state that the standard must not require any vendor
compiler changes or enhancements.
Infrastructure linkage
and/or code generation can both be considered a core part of vendor compiler
capability.
This is no change from
SCE-MI I.
<<End JohnS
We at Cadence understand
the desire for elevating abstraction using a DPI style functional interface in
SCE-MI 2.0. However given that existing IEEE compliant simulators do not
support your proposed DPI-like function based approach w/o being modified we
cannot accept your proposal.
johnS>>
Again, I've not changed IEEE
compliancy requirements. Great pains were taken to avoid this. Everything is
done with supported language constructs as you've seen. There is absolutely no
illegal syntax.
Just as synthesis tools
interpret special attributes or meta-comments in the source code, so does a
SCE-MI II infrastructure compiler interpret the language legal attributes as
we've defined them.
I think you can make the
argument that if you can represent the equivalent functionality with
transformed source, then you can also alter generated code to achieve the same
effect without transformed source.
One can further make similar
arguments for SCE-MI 1.
SCE-MI 1 macros are nothing
more than empty macros. Yet we insert "magic infrastructure"
underneath them automatically as part of an extended infrastructure compile
process.
We have not violated IEEE
compliancy with SCE-MI I any more than we do with replacing empty functions
with "magic infrastructure" underneath in SCE-MI II.
<< End JohnS
Please keep in mind that
while ITC is chartered to define the acceleration interfaces and thus it can
set requirements for acceleration compilers, its decisions are not usually even
known to the developers of simulators. There is a number of logic simulation
tools in use, some of them supplied by the companies represented in ITC and
some are not. Some simulators are open source products maintained by the
volunteer communities. You cannot reasonably expect these tools to be changed
beyond what is required by HDL language standards.
johnS >>
Industry standard IEEE
compliant VHDL parsers that create an intermediate representation of what they
have parsed do not need to change in any way with what I've proposed.
<< End JohnS
Unless you or others
members of the committee can come up with a viable functional based interface
that does not require modifying existing simulator compilers or requiring code
regeneration in simulation flow, I would encourage you and the committee to consider
defining a DPI based solution for SystemVerilog only. Only a solution that is
fully within defined HDL semantics (that does not require code regeneration)
should be considered for Verilog 2001 and VHDL.
johnS:
I think we've made the case
that a function call based approach may be, at worse, slightly more difficult
to implement than a macro based approach but violates no more principles or
agreed upon requirements for SCE-MI 2 than the macro based approach.
<< End JohnS
Response to Per
John actually proposed
now that standard IEEE VHDL simulators get modified to handle his
examples, a position we cannot agree to.
Per>>
I think you misunderstood what John
was proposing. He was saying that a simulation
vendor who wants to support SCE-MI 2.0 could achieve a higher performance
solution if he builds the SCE-MI 2.0 support right into the simulator. But he was certainly not stating that this is
required for implementing SCE-MI 2.0 on a simulator. The function based interface proposed for VHDL
and `old' Verilog can be implemented by anybody and layered on any standard
simulator. No integration is required. The same is true for the macro-based subset
of SCE-MI 2.0, nothing new there. Let's
drop this point, ok?
<< End Per
However, addressing your
questions;
1. We are not aware of a need to modify standard VHDL
simulator (or Verilog 2001 simulator) for supporting Macro based approach in
SCE-MI 1.1 or our proposed macros in SCE-MI 2.0. The macros need to be built in
VHDL (or respectively in Verilog 2001) to meet this assumption and alternating
use model should be assumed in simulation.
Per>>
I was not claiming this. I was trying to figure out why you are
opposed to the infrastructure linker pre-processing the HDL code and emitting
new code with the infrastructure included as a way to implement SCE-MI 2.0
function based interfaces in VDHL and old Verilog. My point is that you have to do this in
SCE-MI 1.1 already especially for pure VHDL.
And I don't see how you can avoid it with the new Cadence proposed
macros either. Even Verilog, which could
probably get you 90% of the way without code pre-processing, requires some code
to be added and modified in order to run on a standard simulator.
> The macros need to be built in
VHDL (or respectively in Verilog 2001) to meet this assumption
Are you referring to implementing
the infrastructure behind the macros here?
Sure, in VHDL you could add some meat to the empty macros, but how do
you get these `full' macros to communicate with the infrastructure. How do you tie into uclock
and ureset, for instance, without altering the
interface of the macro and routing these signals to the macro instances?
> and
alternating use model should be assumed in simulation.
Actually, there is no need to assume
an alternating execution model in simulation.
Even in simulation you can have a multi-process model that allows the
software side to run concurrently with the hardware side, i.e., the
simulator. This is up to the implementation.
SCE-MI 1.1 does not dictate this.
<< End Per
2. We can only invest in transactors that could be used
in both simulation and acceleration mode. This requires that such transactors be
“natively” used by simulation users, including these users who do not need or
consider acceleration. It is also important for transactor developers to do
most of transactor development w/o requiring hardware and for users to use
simulation as a matching (congruent) reference debugging platform. I can
not see how users will agree that we run their code through an Infrastructure
Linker phase that modifies/regenerates their code as a pre-condition to be able
to run it in on a simulator.
Per>>
This means you should use
SystemVerilog and SCE-MI 2.0 to implement your transactors. The SCE-MI 2.0 subset of SystemVerilog is the
only way to model transactors that will run natively in simulators, i.e.,
without ancillary tools such as the SCE-MI infrastructure linker.
Are you really saying this? If not, then show me how VHDL SCE-MI
transactors using macros would somehow better fulfill this goal than
transactors using the function based mechanism.
> It is also important for transactor developers to do most of
transactor development w/o requiring hardware and for users to use simulation
as a matching (congruent) reference debugging platform.
Of course.
This has been agreed upon by the committee time and time again.
> I can not see how users will agree that we run
their code through an Infrastructure Linker phase that modifies/regenerates
their code as a pre-condition to be able to run it in on a simulator.
This is a valid concern. Is this the real reason behind your
opposition to code pre-processing?
SCE-MI 1.1 users are already used to this, so we are talking about new
SCE-MI users that use VHDL or `old' Verilog. The Verilog folks would probably
switch to SystemVerilog, so this point is relevant only to VHDL users. However, since I believe code pre-processing
is required for both macro based and function based
approaches, I think your point is moot.
Essentially, the infrastructure linker is required, and some degree of
code modification is necessary to add the infrastructure, so the users will not
have a choice. I don't think users will
have a hard time with it once they see the benefits of being able to run their accelerateable environments in simulation.
To make progress on these points I'd
like to see you contrast the macro based and function based approaches and come
up with some convincing arguments for why you believe code regeneration is not
required for the macro based approach in pure/strict VHDL.
<<End Per
<End Shabtay
Russ>
I am completely at a loss to understand Shabtay's (I believe inaccurate) distinctions between
a) requiring a supplied library or code regeneration to interpret macros in VHDL and replace them with the appropriate FLI calls to communicate to the C side of the testbench
b) requiring a supplied library or code regeneration to interpret function calls with attributes in VHDL and replace them with the appropriate FLI calls to communicate to the C side of the testbench.
In any case, in not-so-recent-Verilog or VHDL, <something> has to be done since a PLI/FLI is the only way to communicate across the HDL to C interface and these PLI/FLI calls are abstracted by the function or macro (higher level) user interface.
Only in SystemVerilog does the simulation language allow something -- a function call -- to fully specify the messaging exchange between HDL and C.
I could live with SCEMI 2.0 being a SV only spec, but there are VHDL houses out there (Siemens for example) who need an implementation that:
a) will provide continuity
b) will not require a completely separate set of models (on the C side) to be developed for every piece of IP that must run on both SV and VHDL.
To do b), there must be a commonality of approach (either function based or macro based) in both VHDL and SV.
None of the objections raised about using a function + attributes approach for VHDL contain any substantive reasoning. They boil down to "you must modify the VHDL simulator (if you do the function approach)" and (implied) "you don't if you do the macro approach". There is no discussion of WHY that is so, and I've never heard any reason from any party as to why this is so.
<End
Russ
JohnS>
Perhaps a simpler way to
state my response:
If you take say a plain ModelSim (or NCSim, or VCS)
compiler and compile a SCE-MI I design with empty macros today, although
everything is compiled in a language compliant manor, nothing will happen in
the simulation because those macros "had no guts".
Similarly if you take a ModelSim compiler and compile a SCE-MI II design with empty
functions today (or export functions that no one calls), although everything is
compiled in a language compliant manor, nothing will happen in the simulation,
again, because those callees or callers "had no
guts".
But, if, in either case, you
add special infrastructure compilation support so that the empty macros or
functions are filled with "the right substance", you now have
something very useful that supports transaction communication between the HDL
and C environments.
There
is absolutely nothing different in this regard with one approach vs. the other
and if you operate with the premise that the SCE-MI I standard is valid, then
you can made the same case for the SCE-MI II standard.
<End JohnS
Russ>
Shabtay, after re-reading your email for the perhaps 4th time, I think I see what it is you're objecting to. I haven't changed my mind about the dismissibility of your point, and your point was somewhat obscured in your email, but for the sake of clarity, let me try to rephrase it into several points, then I'll comment...
a) the principle objection is that a simple library will not support function-based calls because there are an infinite # of possible function names
comment: agreed, this is one basic difference between the function-based approach and a macro-based approach.
b) objection is that this requires 'modifying standard IEEE VHDL compilers"
comment: disagree. What it requires is something akin to a small piece of what an IFLC does -- call it code regeneration -- to operate on code that has the SCEMI compliant empty functions with attributes. These function calls would be replaced by calls to a finite # of library functions which would use the attributes to implement the necessary binding. The output of this mini-IFLC would then be IEEE-compliant VHDL. Perhaps, to assuage the objection that simulator vendors that don't have emulation products and wouldn't be developing sophisticated IFLC tools couldn't run these SCEMI 2.0 VHDL models in their simulators, this mini-IFLC could be written and made public. All it would have to do is parse the function + attribute and replace it with a standard library function with binding information usable by some FLI-using implementation. Probably could be done in Perl without much difficulty. Algorithm would be:
-- look for function
-- look for attribute
-- if attribute indicates SCEMI2.0 DPI function, replace function with library function call, with all the other info from the function included
so that binding may be done underneath. Perl could input the function name as a 2nd attribute or some other parameter so that the name
would be available to the FLI for binding.
-- on to next function
I wouldn't' expect the guts of this mini-IFLC to be made public; the actual FLI code on both VHDL and C sides would be "exercise left to
student". However, the situation at this point wouldn't be any different (reg'd these smaller simulators) than the situation today with SCEMI1.1. (see my last paragraph below).
Even better
would be, if a simulator had mixed language support, to replace the VHDL
function call with infrastructure that implements a SystemVerilog module
instantiation with actual DPI calls. This would be a harder problem -- converting
a function call to a structural implementation is beyond a one-pass Perl script
-- but shouldn't be difficult for a major-league simulation vendor.
johnS>>
I would venture to say that
even creating a structural implementation would not ever be necessary in a S/W simulator. Only when going to an emulator that takes a
synthesized gate level representation might this become necessary.
But in that case, infrastructure synthesis was already a requirement for SCE-MI
I and this does not really add much to that requirement.
<< End JohnS
The advantage would be that once this is done, there literally is nothing to do on the C side. Of course, if a simulator really had mixed-language support, why wouldn't its SCEMI2.0 models be done in SystemVerilog to begin with... and avoid all this problem?
c) objection: any "code regeneration" requirement is reason to abandon the function-based approach for VHDL / old Verilog
comment: disagree. The benefits of a common C side for modeling far outweigh this one-pass filtering requirement. As I see it, the paramount goal of this SCEMI 2.0 initiative is to enable verification IP to be written such that it ports seamlessly from pure simulation to emulation. Also as I see it, the only way to move in that direction is to use a simulation standard for emulation testbench messaging (DPI for SCEMI 2.0). Everything else must flow from that. Arcane macros are a dead-end for this goal -- no simulation-only IP will ever be written using them.
d) "you cannot expect these tools (other simulators from vendors that don't' have emulation products) to be changed beyond what is required by HDL language standards"
there is no expectation or requirement that any tool need be changed. It's comments like these that obfuscate the point that there is some filtering or "code regeneration" required for a function-based solution in VHDL. This filtering is independent of the simulator which need not be changed in any way.
Another
comment: In practice, running SCEMI 1.1 testbenches can't be done on
simulators that don't support SCEMI1.1 explicitly because these simulation
vendors don't make public their SCEMI 1.1 libraries. Perhaps the code
regeneration methodology for SCEMI 2.0 support of VHDL would make it easier to
port testbenches to the smaller simulators because the C-side requirements
would be less than for SCEMI 1.1 once the straightforwardness of code swapping
on the VHDL side is assumed.
Shabtay>
My proposal
to John to illustrate using Verilog 2001 the proposed function-based approach
for simulation focuses the discussion. I am truly hoping that John will pick
this up and share the results with us so we can move forward on this crucial
point.
You
rephrased some of the points in my email in a way that I disagree with. In particular
you implied that we proposed a SystemVerilog only SCE-MI 2.0 standard. I don’t
know if it makes sense for me to go through a lengthy response to each at this
time. I would only state again that we are always stated that SCE-MI 2.0 must
support all 3 HDLs on the HW side including
SystemVerilog VHDL and Verilog 2001. The question on the table is only how
it should support these and not if it should support these.
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.
<End Shabtay
<End Russ
Shabtay>
I think that we can and
should narrow the discussion at this time.
When you sent your
proposal you stated (I quote):
“The vendor can modify
their compiler so that the empty procedure is automatically replaced directly
with generated native code that hooks into an infrastructure implementation
that directly communicates to C using whatever VHDL foreign language interface
(FLI) that is supported by that vendor.”
Please define which
vendor you are referring to; simulation vendor or acceleration/emulation
vendor? It is reasonable to ask acceleration vendor to modify the back-end
compilation flow. I have no objection that acceleration vendors would fill the
empty functions “with the right substance” for any of the 3 language domains.
As to a simulator vendor; he has nothing to do with SCE-MI, and it is not
reasonable to require him to change a compiler which BTW was not required in
SCE-MI 1.1 and when using in general a macro based approach.
Russ indicated that quite
a “mini-IFLC” can generate EEE-compliant VHDL code (and I assume Verilog 2001
code). If this is as simple as that, can you take your source code example with
DPI import and export declaration, use your proposed attributes based approach
and empty function calls, and show in Verilog 2001 that the library that
you generated by the infrastructure linker (implementing the communication
channels underneath) can be instantiated from the empty function calls w/o
modifying the source code or modifying the simulator compilers? Can you
show how you implement transaction communication between the HDL and C
environments for import and in particular export function using standard API in
simulation? For the latest, if you want to show how you implemented this on top
of SCE-MI macros, this will also prove the point. Using Verilog 2001 will allow
all of us to quickly evaluate the simulation flow and assess if there are any
issues we need to resolve for VHDL.
I am not asking for an
optimal and final version of the flow for simulation. The intent is that you
will show the stated simple implementation as a proof of concept and as illustration
of the proposed simulating flow.
<< End Shabtay