From: Michael McNamara (mac@surefirev.com)
Date: Wed Apr 22 1998 - 13:46:01 PDT
Adam Krolnik writes:
>
> 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
A very simple fix for timescale and IP is a push and pop time scale
directive:
`push_timescale
`timescale 1 sec/ 10 ms
module my_slow_ip();
endmodule
`pop_timescale
<p>Basically, `push_timescale tells the verilog system to save away
whatever is the current timescale
`pop_timescale restores the most recently pushed timescale.
One can nest arbitraily deep in pushing timescales.
popping too many timescales is an error.
1) This way existing code isn't broken,
2) and ip vendors can be proactive in shipping good code;
3) users can easily protect them selves by wrapping 'timescale
suspect' code:
`push_timescale
-y vendor1lib.a
`pop_timescale
`push_timescale
-y vendor2lib.a
`pop_timescale
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:48 PDT
and
sponsored by Boyd Technology, Inc.