Subject: Re: Verilog-AMS - Issue 15: `include
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jul 09 2002 - 14:57:30 PDT
> From owner-sv-ec@server.eda.org Tue Jul 9 13:47:17 2002
> > Further, 'include' is not a reserved word, so users could have:
>
> Actually, 'include' _is_ a reserved word. See Annex B of 1364-2001.
>
> But the point is well made that for a preprocessor you want an out-of-band
> symbol, one which cannot occur except as input to the preprocessor. Since
> '#' is already used in several places in the verilog syntax, it would be
> awkward to try to extend the preprocessor to recognize '#' as a preprocessor
> token in certain cases and not in others.
>
> Presumably if you were to allow '#include', then you would want to allow
> '#define', and '#macro', for a macro reference. I think that allowing
> '#macro' would completely break the syntax. And if you didn't have
> '#macro', then why make a special exception just for '#include'?
>
> Paul
>
>
The reserved word argument doesn't apply to independent preprocessors.
Similarly, if you run Verilog through cpp the '#' from the delays will
cause you a problem already.
If you don't have an independent preprocessor then you can allow the
'#include' outside a module scope and there wouldn't be a conflict (unless
you are allowed #<delay> in $root), but then if "include" is reserved there
still isn't a conflict.
Yep, #define,#ifdef... would be good to, ideally I should be able to use the
same header files for my C and my SystemVerilog. Duplicated data is a major
source of errors, and the last project I worked on had lots of it to make
the C++/Verilog interfaces work.
Kev.
This archive was generated by hypermail 2b28 : Tue Jul 09 2002 - 14:59:23 PDT