Re: supporting DPI in VHDL - possible scenarios for implementation

Per,

Thanks for these responses.

I was going to respond to Shabtay's e-mail in detail as well
but you've made all the points I was going to make and I think
I can say your version better articulated than I could have
done.

The one thing I would add to this is, in response to Shabtay's
request that we show a Verilog 2001 alternative implementation
I would make the point that the approaches I mentioned in my
initial writeup for VHDL can be applied more or less equally
in Verilog 2001. And with Verilog 2001 we can further say
that the wrapper layers can use PLI as opposed to a vendor
specific VHDL FLI.

Your initial point below is key. The operative word is "can".
I'm not saying a vendor is required to modify the native
code generation in their compiler. Merely that that is one
option - and possibly the most optimal one. The other option
is source code transformation by the infrastructure linker.
Any 3rd party SCE-MI implementor could do the latter option
on any industry standard simulator. These were the main points
I was trying to make.

-- johnS

Per Bojsen wrote:
> Hi Shabtay,
> 
>  > “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 was your quote of John's proposal.  Note that it says the vendor
> *can* modify their compiler.  This implies a choice not a mandate.
> John is simply pointing out some possible optimizations an
> implementation can take advantage of.
> 
>  > Please define which vendor you are referring to; simulation vendor or
>  > acceleration/emulation vendor?
> 
> The only vendors we are interested in in this committee are SCE-MI
> vendors.  In this case John is talking about SCE-MI vendors that also
> happen to be simulation vendors and who are interested in providing
> an integrated solution, i.e., essentially a simulator with builtin
> SCE-MI support.
> 
>  > 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.
> 
> And he is not required to do anything to support SCE-MI in 2.0 either.
> The SCE-MI 2.0 implementation can be provided as a third-party addon
> that runs on top of the simulator.
> 
>  > 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?
> 
> What do you mean when you say `w/o modifying the source code'? Is this
> your `no code-regeneration' requirement or are you simply stating that
> the source code should not have to be rewritten by the user before
> it can be passed through the infrastructure linker?
> 
>  > 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.
> 
> This is easy to do but it won't satisfy your `no code-regeneration'
> requirement.  After all, replacing function calls with SCE-MI macros
> and associated infrastructure is going to require some modification
> of the HDL code.  I assume you are aware of that so is code regeneration
> actually OK?
> 
> Per
> 
> 

-- 

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
________________________________________________________________