Re: Compiler directives ( timescale)

From: Eli Sternheim (eli@interhdl.interhdl.com)
Date: Wed Apr 15 1998 - 08:56:06 PDT


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

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

<p> Other comments encouraged.

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


This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:52:48 PDT and
sponsored by Boyd Technology, Inc.