RequireResolution < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>RequireResolution (2020-02-17, JimLewis) (raw view)EditAttach
---+ Required Simulation Resolution

%TOC%

---++ Proposal Information
   * Current Owner: JimLewis, ...
   * Contributors: JimLewis, ...
   * Date Proposed: 2013-Dec-23
   * Date Last Updated: 2013-Dec-23
   * Priority:
   * Complexity:
   * Focus: Testbench
   * Related Issues: None
   * Competing Issues: None
---++ Requirement Summary

Provide a method for a design to note the minimum simulation time units it requires

---++ Rationale

VHDL programs produce very strange bugs when loaded with a simulator resolution that is too large for a design.

For time units less than the current simulator resolution, does a simulator return a 0 time value? For time units in a "wait for" does a simulator treat the same as "wait for 0 hr"?

---++ Proposal 1: Function Call

Create a function (in package env) that returns a boolean true or false on its call:

<pre>function CheckResolution( A : time) return boolean is
begin
  assert A &gt; 0 hr report "Simulation resolution too small" severity failure ; 
  return A &gt; 0 hr ;
end function CheckResolution ; </pre>

Then declare a constant in the design unit declarative area (most useful for packages):
<pre>constant VALID_SIM_RESOLUTION : boolean := CheckResolution(1 ps) ; </pre>

In an Architecture, use an assert statement without the constant:
<pre>assert CheckResolution(1 ns) report "Design:  A of E" severity failure ; </pre>

---++ Proposal 2: Language Syntax

Replace the contents of this section with a suggestion. I am hoping for something that does not add new keywords.

---++ Comments
---+++ General

Main.DavidKoontz - 2013-12-24

5.2.4.2 Predefined physical types:
<div title="Page 54">

... It is an error if a given unit of type TIME appears anywhere within the design hierarchy defining a model to be elaborated, and if the position number of that unit is less than that of the secondary unit selected as the resolution limit for type TIME during the elaboration of the model, unless that unit is part of a physical literal whose abstract literal is either the integer value zero or the floating-point value zero.

Which says you could set the resolution limit to ns and specify 0.7 ns and it will get truncated to 0.0 ns, and demonstrates the value of your proposed functional call where a behavioral description uses say a wait for time_expression to perform and would fail (or do odd things) when that time is truncated.

Without regards to seconds and minutes you could do the same thing by adding hundredths or tenths of the necessary unit to 0 and testing for 0 because it truncates. Do you need that test in package env? Why does there have to be a 'system' package kill switch because someone wrote a behavior based on a possibly invalid assumption?

You could also note that an implementation dependent method of setting the resolution likely already requires user action. Is there really a need to protect the user from the consequences of their actions?

</div>

---+++ Arguments Against

---++ Supporters
Topic revision: r4 - 2020-02-17 - 15:34:59 - JimLewis
P1076/Ballots