All, 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. --------------------------------------- --- 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: Tuesday, October 04, 2005 9:59 AM To: bojsen@zaiqtech.com Cc: itc@eda.org Subject: RE: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825) Hi Per, See my response to John on his latest proposal. John actually proposed now that standard IEEE VHDL simulators get modified to handle his examples, a position we cannot agree to. 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. 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. Thanks, Shabtay >-----Original Message----- >From: Per Bojsen [mailto:bojsen@zaiqtech.com] >Sent: Wednesday, September 28, 2005 11:37 AM >To: Shabtay Matalon >Cc: bojsen@zaiqtech.com; itc@eda.org >Subject: RE: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825) > >Hi Shabtay, > >Per> The choice of HDL should be transparent to the software side, >Per> i.e., the user should be able to use Verilog 2001, SystemVerilog, >Per> and VHDL interchangeably without having to rewrite the software >Per> side > >Shabtay> Very important goal that should be attempted, but one that >Shabtay> cannot override the other principles. > >Shabtay> I didn't state that defining a function based interface in old >Shabtay> Verilog/Verilog 2001 and/or VHDL is impossible. John's latest >Shabtay> proposal doesn't meet the principles I outlined. If there are >Shabtay> other proposals that do, we should evaluate them. > >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? > >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? > >Thanks, >Per > >-- >Per Bojsen Email: <bojsen@zaiqtech.com> >Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com >78 Dragon Ct. Tel: 781 721 8229 >Woburn, MA 01801 Fax: 781 932 7488 >Received on Tue Oct 4 10:26:11 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 04 2005 - 10:26:13 PDT