Re: `define __SIMULATOR__

Geoffrey.Coram wrote:

>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
>
>
I would suggest that you just say the simulator should provide one or
more unique predefined macros to identify itself, I don't think it
needs to be any special format, but if the LRM is using __*__ for
official definitions you might want to exclude those. If vendors have
already provided such macros then nobody needs to do any extra work.

Kev.

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

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