RE: `define __SIMULATOR__

It's probably better not to do that at all, and instead define
capabilities
or non-capabilities, e.g. if a simulator can handle m-factor it would
define
(say) __VAMS_M_FACTOR__, and maybe define the language compliance level
too (say)
__VAMS_MAJOR__ and __VAMS_MINOR__ (2 and 1 for the current LRM). An
implementation
supporting all 2.1 but only parts of 2.2 would set the language level
(major/minor)
at 2/1 and add defines for the extras it does support.

The vendors can define whatever other things they need/want to, but it
would
probably be a good idea to maintain a list on the verilog-ams website to
avoid
clashes.

Kev.

Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862

> -----Original Message-----
> From: owner-verilog-ams-devmod@eda.org
[mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of
> Geoffrey.Coram
> Sent: Tuesday, May 25, 2004 10:20 AM
> To: VerilogA Device Modeling Reflector
> Subject: `define __SIMULATOR__
>
> The current LRM draft suggests that simulators `define
> a token __COMPANYNAME_SIMULATORNAME__. However, what
> happens when an eda company is bought out?
>
> Eg., __META_HSPICE__ became __AVANTI_HSPICE__ became
> __SYNOPSYS_HSPICE__
>
> Should the `define simply be __SIMULATORNAME__?
> The name of a commercial simulator is usually a trademark;
> is anyone aware of conflicts in academic simulators?
>
> (The proposal mentioned "Spectre" as a piece of code
> from Berkeley, but apparently Cadence has trademarked
> the name and Berkeley chose a new one.)
>
> -Geoffrey
Received on Tue May 25 10:41:19 2004