On 7/04/2015, at 6:55 am, Paul Koning <[email protected]> wrote:
> >> On Apr 6, 2015, at 2:48 PM, Tristan Gingold <[email protected]> wrote: >> >> On 05/04/15 18:03, Adam Jensen wrote: >> ... >>> With the time-resolution fixed to femto seconds, the total simulation time >>> is limited to about 2.6 hours. >>> >>> 2^63 * 1e-15 sec ~= 153.723 min >>> >>> If events in a model occur on the scale of minutes, the simulations are >>> very limited. >> >> Yes, but is there a real case for that ? In microelectronics, >> propagation time is not in minutes! > > True, but elapsed time between external inputs might be. Suppose you’re > modeling a data capture system, with a clock on the order of milliseconds, > and external events minutes or hours apart. The propagation delays in that > case are essentially zero, but the behavior has time units matching the clock > period, and for a slow clock situation, femtoseconds are not really useful. VHDL models are event driven not time driven, the notion of time is superimposed on the occurrence of events. You can model an alarm clock chip in VHDL and synthesize it. Simulation (a computer model of) doesn't require you run the model for 24 hours (or 7 days, or ...), that would be emulation (- Computing reproduce the function or action of (a different computer, software system, etc.). Verification requires you produce observable events, and to do so you can manipulate the design model state. Emulation requires you generate all the events. I personally favor the idea of implementing an assignable resolution limit. If I ever finish and release my implementation it will have it. However, it's of limited usefulness. Todays 'microelectronics' requires timing resolution finer than the nanosecond scale. You're bound to trip over someone for whom a thousand times increase in time (using ps) isn't enough to emulate time driven simulation incorporating "microelectronics" much less Adam's "other than microelectronics". You could also note that from IEEE Std 1076-2008 5.2.4.2, the use of nested 'may's and Annex D, Potentially nonportable constructs, you can't expect resolution-limit use to be portable. The question is whether or not the VHDL standard will ever embrace sufficient accuracy to relate to time driven modeling. It doesn't appear to be within the scope of the VHDL language. See the Introduction in the standard. And if it did embrace it, resolution limit would likely be required. And as for Adam's "other than microelectronics" He could always define a new physical type with it's own units and use some conversion routines to convert it back and forth to type TIME with a resolution limit scaling. A 32 bit INTEGER ranged Physical Type would be portable and have the range for a years worth of milliseconds. You could equate a millisecond to a femtosecond. You can deal with larger values of the new time type by first converting them to type Time and using multiplying operators, see 9.2.7 Multiplying operators, the second table. There isn't a requirement that a report statement provide the simulation time, see 10.4 Report statement, para 5, a) through d). This shows why always providing it can limiting. A to_string or a 'IMAGE would provide a proper representation of your new physical type. See 9.7 String representations. There could also have a routine for scaling to secondary units as a string instead of 'IMAGE and so on. You'd use a conversion routine to Time where you'd want to provide an expression of type Time for a delay, etc. There are places where a Time expression is required to be static which would require a constant declaration for type Time, which can have an initial value from a conversion routine. "Admiral, if we go by the book, like Lieutenant Saavik, hours could seem like days." Substituting femtoseconds for hours and milliseconds for days. It does the same thing as a settable resolution limit albeit with a slight crudity with savings grace of being portable (unless someone were to rely on some other nonportable feature as well). _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
