RE: `define __SIMULATOR__

Geoffrey,

Just a tought.
__SIMULATOR__ means the the vla code will be parsed
then used by the same target simulator.
If a company writes a VLA compiler that will target
different simulators at the same time and if its compiler
has specific VLA constructs then the __SIMULATOR__ name will
be unappropriate. (may-be this is something that will never happen).

Laurent Lemaitre
Freescale - Geneva

> -----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 7:45 PM
> To: Kevin Cameron
> Cc: VerilogA Device Modeling Reflector
> Subject: Re: `define __SIMULATOR__
>
>
> Kevin -
> That sort of detection is not what I'm after.
>
> In our simulator, we support some non-standard syntax;
> one simulator prefers to install GMIN differently than
> all others; some simulators have bugs that I've needed
> `ifdef to work around (in an inefficient way that I
> didn't want to use everywhere).
>
> That's what I need __SIMULATOR__ for.
>
> -Geoffrey
>
>
>
>
> Kevin Cameron wrote:
> >
> > 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.
>
Received on Wed May 26 01:55:03 2004