Action item: solution to Verilog data coercion issue

ITC fellows:

As one of the few participating users on the group, I hope I can add some
practicality and vision to the discussion of this issue.

BRCM believes that the most important reason to have a SCEMI 2.0 standard in
the first place is to 
  * enable a unification of simulation and emulation environments at
companies who do both
  * instigate/enable verification IP providers to write their IP in a format
that can be used in both simulation and emulation.

With this in mind, the optimal solution is verification IP models written in
SystemVerilog using a DPI-based messaging channel  between the algorithmic
side of the testbench (the HVL side) and the DUT (the HDL side). On top of
this, a low-density transaction approach (transactions that are packed with
information and therefore can be infrequent), gives the highest performance
in both simulation and emulation.

We (BRCM) support a standard that encourages the industry to go this way,
and discourages other approaches, or any incentive to delay this optimal
outcome.

So with respect to the VHDL side of things, a couple of observations.
  * VHDL is a small minority of the worldwide simulation/emulation/IP space,
and anything done to support VHDL should not impact an optimal specification
for SCEMI 2.0 in the rest of the space
  * Functions/attributes et. al. are part of the VHDL standard and provide a
means of allowing verification IP providers to write models that are not
so architecturally different from the SystemVerilog models they'll write
using DPI that the task of supporting both will be onerous.
  * These VHDL models won't run in pure simulation without some library
support from EDA vendors but that's unavoidable in any scenario.

With respect to the Verilog (pre-SystemVerilog, or "old Verilog" ) side:
  * All major verilog simulators are adding support for SystemVerilog within
their (standard) release simulators. I.e., it's not that one has to go to a
different path and run a different executable to simulate a SV testbench --
usually it's just a command line option to include SV functionality.
  * For emulation, verilog source code has to be run through an
infrastructure linker. That process can (ought to) remove any code that is
SystemVerilog specific -- such as DPI syntax -- and replace it with some TBD
syntax which could be gates or could be (old)Verilog compliant
infrastructure, if necessary.
  * Once that is done, all that is left is (old) Verilog which can be run
through synthesis tools (that don't yet support SystemVerilog) or other
tools of the same ilk -- whether one orignally had DPI calls or black box
structural instantiations is irrelevant to the rest of the flow.
  * So, if the verification IP provider chooses to implement the BFM part of
the transactor in (old)Verilog to be safe for tools that don't support SV,
that doesn't require any SCEMI 2.0 specification considerations other than
the data coercion between (old)Verilog data types in the BFM and the DPI
function formal arguments in those DPI calls. I assert that these coercions
that need to be supported could easily be listed in a table that would fit
in a half page of the spec.

So, BRCM supports SCEMI 2.0 supporting both SystemVerilog and (old)Verilog
using true SystemVerilog DPI syntax -- enabling models to be run in a
SystemVerilog simulation AS IS, and specifying that an IFLC eliminates the
SystemVerilog DPI calls and outputs intermediate design representation to
tools that might not support SystemVerilog constructs. IP vendors can choose
to write their BFMs in SystemVerilog or (old)Verilog as they see fit. We
believe that sooner rather than later, the reasons for using SystemVerilog
will be compelling to most if not all -- especially since they generally
won't be worried about synthesis into an emulator since the majority of
their market will be for pure simulation. (Actually, they will be wanting to
write those BFMs in a non-synthesizeable behavioral style -- and that is a
subject that the committee has deferred for the time being).

This approach will provide a means for verification IP providers to write
their models in a standard format that is (primarily) for simulation, and
will port seamlessly to emulation.

Usage of a macro instantiation approach will doom this desired outcome. It
needs to be either discouraged or (preferably) abandoned by the ITC. There
is a zero chance that any outcome with verification IP providers supplying
models that run in simulation AND emulation will happen unless they have a
standard that makes sense and is comfortable for customers interested in
simulation only, not emulation.

---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------