Re: Next priority: Maximum value of simulation time

I don't think a local static will work because it will get created before main() if I recall the correct semantics of C++. We could however create a pointer...

namespace sc_core {
   sc_time sc_max_time(void) {
    static sc_time const* max_time_ptr( 0 );
    if ( ! max_time_ptr )
    {
      double resolution_secs = sc_get_time_resolution().to_seconds();
      max_time_ptr = new const sc_time(double(~0ULL)/resolution_secs, SC_SEC);
    }
    return *max_time_ptr;
  }
}

NOTE 1: I tested the preceding at for both elaboration and run-time scenarios.
NOTE 2: Performance should be a big issue since this is unlikely to be used frequently.

------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL, verification and DFT needs)
Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609

On Sep 13, 2010, at 10:44 AM, Philipp A. Hartmann wrote:

> John,
>
> my usual nitpick:
>
> The top-level const on the return-type is more or less ignored in C++.
> So I would prefer to either return a plain value, or maybe even a
> reference to a local static:
>
> sc_time /* const & */
> sc_max_time()
> {
> static sc_time end_of_days =
> sc_time( double(~0ULL) / sc_get_time_resolution().to_seconds()
> , SC_SEC );
> return end_of_days;
> }
>
> Comments?
>
> I don't think that there is the caveat of changing values with this
> definition, though. The user can't change the time resolution, after
> any sc_time objects have been created (5.10.3). And calling
> sc_max_time() obviously creates one ... :-)
>
> Greetings from Oldenburg,
> Philipp
>
> On 13/09/10 17:18, john.aynsley@doulos.com wrote:
>
>> Having discussed this internally, we've realized that a const does not
>> work because the time resolution can be changed during elaboration. The
>> following definition works, with the caveat that its value will change if
>> the time resolution is changed. Its value cannot change during simulation.
>>
>> namespace sc_core {
>>
>> const sc_core::sc_time sc_max_time()
>> {
>> return
>> sc_core::sc_time(double(~0ULL)/sc_core::sc_get_time_resolution().to_seconds(),
>> sc_core::SC_SEC);
>> }
>>
>> }
>>
>> John A
>>
>>
>>
>> From:
>> David Long/doulos
>> To:
>> john.aynsley@doulos.com
>> Cc:
>> owner-systemc-p1666-technical@eda.org, systemc-p1666-technical@eda.org
>> Date:
>> 13/09/2010 15:23
>> Subject:
>> Re: Next priority: Maximum value of simulation time
>>
>>
>>
>> John,
>>
>> I was thinking of something along the lines of:
>>
>> Constant SC_MAX_TIME represents the maximum simulated time that may be
>> reached.
>>
>> The definition could be implementation-defined. Alternatively it could be
>> implemented by something like:
>>
>> const sc_time SC_MAX_TIME =
>> sc_time(double(~0ULL)/sc_get_time_resolution().to_seconds(), SC_SEC);
>>
>> There is a constant UINT64_ZERO in sc_nbdefs.cpp that could be used in
>> place of 0ULL but that is not mentioned in IEEE 1666-2005.
>>
>> Dave
>>
>>
>>
>> From:
>> john.aynsley@doulos.com
>> To:
>> david.long@doulos.com, systemc-p1666-technical@eda.org
>> Date:
>> 13/09/2010 13:46
>> Subject:
>> Next priority: Maximum value of simulation time
>> Sent by:
>> owner-systemc-p1666-technical@eda.org
>>
>>
>>
>>
>> Dave,
>>
>> You wrote:
>>
>> "5.10.1 states that time shall be represented internally by an unsigned
>> integer of at least 64 bits. However, it does not provide any method to
>> create an sc_time object that corresponds to the largest representable
>> time (the sc_time constructor that takes a numeric value has double
>> sc_time_unit arguments). One way to represent the maximum time would be to
>> declare a "constant" sc_time object (e.g. SC_MAX_TIME) that took acount of
>> the global time resolution that applies to the current simulation."
>>
>> Could you provide a spec and/or implementation for what you propose?
>>
>> Thanks,
>>
>> John A
>>
>
>
> --
> Philipp A. Hartmann
> Hardware/Software Design Methodology Group
>
> OFFIS Institute for Information Technology
> R&D Division Transportation · FuE-Bereich Verkehr
> Escherweg 2 · 26121 Oldenburg · Germany
> Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.