>To me, it seems reasonable to just strike this problematic sentence.
That would certainly be the simplest solution.
It might also be desirable to add a statement that points out that taking
the scaled value produced from a time literal, and using that value in a
module with a different timescale, will not produce the desired delay.
>(In a future release, perhaps a true time data type could be added as
>an enhancement.)
At which point the literals could be of that type, and the existing
scaling behavior would be the automatic type conversion from that time
type to a numeric type. So this could still be made backward compatible
with the existing time literals.
BTW, my original question on this was a very general one about how time
literals worked. Peter Flake explained how the scaling worked, and I
agreed that this resolved my questions. But the extra rule in this
sentence was not part of that discussion, and seems to have been added
afterwards. It appears that somebody threw in this change in the mistaken
idea that it would solve the more general problem, which actually requires
something like a true dimensioned time type.
Given the lack of time to design such a thing now, I agree with Brad that
we should eliminate the problematic sentence.
Steven Sharp
sharp@cadence.com
Received on Thu Nov 4 12:53:44 2004
This archive was generated by hypermail 2.1.8 : Thu Nov 04 2004 - 12:54:04 PST