RE: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825)

Hi Shabtay,

Russ has already offered a good counterargument to your key points, but
I'd like to add a few more observations of my own anyway.

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

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?

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

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.

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

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.

Per