From: Stuart Sutherland (stuart@sutherland.com)
Date: Wed Apr 15 1998 - 10:56:25 PDT
BAD MSG:
Actually, `timescale is NOT permitted within a module in Verilog-XL, and I
hink most (if not all) other simulators. I thought this was specified in
the LRM, but I couldn't find it (many of the other compiler directives in
the LRM explicitly state whether they can be used within or without a module).
X-Lines: 96
Content-Type: text/plain; charset="us-ascii"
Content-Length: 3868
X-Status: $$$$
X-UID: 0000000387
Status: RO
Personally, I do not see a need for changing the nature of `timescale. Its
behavior of affecting all modules which follow the directive is consistent
with all other compiler directives, and has the same practical uses as well
as inherent hazards. It simply requires that modelers have the common
sense and self discipline to place a `timescale directive before their own
modules. That is just good coding style. In many (all?) aspects of
Verilog, good coding style is a discipline which is not imposed by the
language.
The one thing lacking in the current `timescale behavior is that there is
no standard default time unit and precision. This was discussed for the
1995 standard, and decided to purposely omit from the standard because
every existing simulator had implemented different defaults (or no default
in the case of Verilog-XL)
At 03:56 PM 4/15/98 -0000, Eli Sternheim wrote:
>
>A very good point. Another ugly feature of `timescale is that it can
>appear anywhere inside a module. I am not sure if it means that the
>current module is affected or only the next one. It would be much
>cleaner to limit it to appear only between modules.
>
>Eli
>
> Delivered-To: eli@interhdl.com
> X-Authentication-Warning: gw.boyd.com: majordomo set sender to
owner-btf@boyd.com using -f
> From: Adam Krolnik <adamk@cyrix.com>
> Date: Wed, 15 Apr 98 10:31:09 +0600
> Sender: owner-btf@boyd.com
> Precedence: bulk
>
>
> Good morning:
>
> After investigating `timescale functionality I am wondering if this
functionality
> is adequate for applications like coreware and IP modules.
>
> The current functionality of timescale is similar to other compiler
directives -
> they remain in effect for subsequent source files until altered by
another compiler directive or reset. I don't understand how one would
effectively use compiler directives
> in an environment where local source code is combined with foreign
source code.
>
> If one wanted to distribute a IP source which needed a specific
timescale, this
> could be added to one or all of the files comprising the IP source.
Now the
> application that wishes to use this IP source needs to specify it's own
timescale
> 1. because the first file (or all files) need it, and 2. you probably
want the
> local source to run on a similar time scale. But there really is no way
to specify
> a time scale for most of the source, unless all local source files contain
> a timescale directive (and then that is not very easy to modify since it's
> distributed through all the source.)
>
> It would be nice to have some scoping of compiler directives. Maybe a
global
> timescale (which could be overridden by individual modules and revert
to the
> global one at the end of the module), module specific timescales, etc.
Maybe
> a way to specify a timescale using a preprocessor macro and then use that
> macro. Then one could alter the macro definition to change the timescale.
>
>
> Other comments encouraged.
>
>
> Adam Krolnik
> Verification Engineer
> Cyrix - NSM.
> Richardson TX. 75085
>
>--
>Eli Sternheim interHDL, Inc.
>4984 El Camino Real, Suite 210 Los Altos, CA. 94022-1433
>phone: 650-428-4200 fax: 650-428-4201
>email: eli@interhdl.com
>web: http://www.interhdl.com ftp: ftp.interhdl.com
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland.com
Specializing in Verilog HDL consulting and training. Publisher of the
popular Verilog HDL and Verilog PLI quick reference guides.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:48 PDT
and
sponsored by Boyd Technology, Inc.