Re: [vhdl-200x-ft] to_string (time, resolution) problem

Hi Steve.

Why not just allow both functions? Overloading
should work.

-- 
                          John
                      jwill@AstraGate.net
                      John Michael Williams
Bailey, Stephen wrote:
> Dave,
> 
> Don't drop this.  Even though the function cannot be implemented in VHDL today such that it handles all values (easily), it can be semantically defined.  The package bodies are executable specifications.  There's no requirement that they be the literal implementation in tools.
> 
> -Steve Bailey
> 
> 
>>-----Original Message-----
>>From: owner-vhdl-200x-ft@eda.org 
>>[mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of David Bishop
>>Sent: Monday, September 27, 2004 2:18 PM
>>To: vhdl-200x-ft@eda.org
>>Subject: [vhdl-200x-ft] to_string (time, resolution) problem
>>
>>I was playing around with the to_string function:
>>
>>   function to_string (
>>     VALUE     : in TIME;
>>     JUSTIFIED : in SIDE  := right;
>>     FIELD     : in WIDTH := 0;
>>     resolution : in TIME := Sim_Resolution
>>     ) return STRING;
>>
>>and looking into implementations.
>>
>>In the LRM, there is only one way to get "time" into any other format:
>>function "/" (anonymous, anonymous: TIME) return universal_integer;
>>
>>Since 1 hr / 1 fs > integer'high there is no way I can do 
>>this, because I need to use "real" math to manipulate the number.
>>
>>Can I recommend that we drop this one and go back to:
>>   function to_string (
>>     VALUE     : in TIME;
>>     JUSTIFIED : in SIDE  := right;
>>     FIELD     : in WIDTH := 0
>>     ) return STRING;
>>
>>Though I like the idea of the deferred constant "sim_resolution".
>>It gives you something to check in your testbenches to make 
>>sure that you have the correct simulation resolution set.
>>
>>If somebody comes up with a clever idea, we can always 
>>revisit it later.
>>
>>-- 
>>David W. Bishop dbishop@vhdl.org       All standard disclaimers apply.
>>
> 
>