Contrary to what was written and implied, THERE IS AMBIGUITY IN THE OUTPUT OF THE u operator. For a given f(v,Z,t), the output of a u(f(v,Z,t)) operation will return an output which is unity when the argument is greater than zero, and zero when the argument is less than zero. When the argument is zero, it is treated somewhat like an xSPICE logic element. That is to say, it becomes indeterminate, and like the xSPICE logic elements, returns an intermediate value.

The returned value is half-way between zero and one or 0.5, similar to that of the xspice element which returns a value mid-way between the values set for the Xspice high and low output values.

The respective values are found in version 5 through the SIMULATIONS/SPICE SIMULATIONS/MIXED MODE drop down selection sequence through the variables:

In the Xspice logic elements, if the input is less than bb_adInLow = .5 it is interpreted as a logic low input, whereas if the input is greater than bb_adInHigh = 4.5 it is interpreted as a logic high level. Between these levels the input is treated as an indeterminate value, resulting in an output equal to (bb_daOutLow = 0 bb_daOutHigh = 5) /2 or 2.5 volts.

Now for the 'u' operator, the output variations are zero and one, hence the indeterminate output value = 0.5. Apparently there is a value for an argument ever so slightly greater than zero which will cause the 'u' function to return a logic one, and another ever so slightly less than zero which causes the function to return a logic zero.
Consequently, if one were to use a generator to produce an output which pulsed between zero and some value, and to use voltage as an argument for a 'u' function, the output would vary between 0.5 and 1.0 (after an initial transient depending on whether the node was set to a level at the start of a simulation or not.)

Many of my models using these functions had/have operands that were/are real values, and bipolar in nature. These would only present an indeterminate output level rarely if ever, as the likelihood of a real variable being exactly zero for any length of time is slight. The problems would arise in using those digital models for digital simulations with input signal values that varied between zero (or some small positive level) to a higher level.

Generally I tested for these cases but not always. I made an occasional error in testing these models by being lazy and using sine wave inputs in many cases. I usually included a threshold value for these devices in any event, save for comparisons between real levels. To verify this problem, the model in Figure 1 was created:

Figure 1a
Ustep test circuit

For this first test, the expression for the B1 generator is:

and for B2 it is:

A graph of this circuit is shown in Figure 2a following:

Here we see that N2 presents an output that varies between one and 0.5V (after the initial time zero) - whereas, the zero argument presents a constant 0.5V output. Let us now modify B1 to be:

and B2 to be:

The graph becomes as shown in Figure 3a following:

Figure 3a
Ustep test circuit1 graph2

Here we see that with the test of the input being at the upper limit for B1, the N2 curve now varies between unity and 0.5, instead of between 0.5 and 1.0V. Interesting. This might be useful sooner or later. The curve for N3, with a test value of 0.5, produces the desired result. Let us do one more test, changing the input voltage v1 to vary between 0.3 and 3.3V. B1 and B2 will be unchanged. The graph for these conditions is in Figure 4a following:

Figure 4a
Ustep test circuit1 graph3

Here we see that the curves behave as expected. Not shown is an zoomed in trace of the rise and fall times, for there is where we might expect to see problems if a zero argument were present.

Not shown are several traces where the input has been applied to an RC filter to slow down the transitions. The traces give no indication of problems with a 0.5 unexpected output level.

The conclusions are, that whenever operating with a unipolar type output there must be a test for the variable(s) in the argument being greater than some intermediate threshold level between the minimum and maximum input levels where switching is expected to occur.

Now inasmuch as there were some questions regarding the ustep function, it seems reasonable (for version 5.15+ which has logical equation capabilities) whether this will result in similar problems for an IF … THEN … ELSE … OR an ITE expression. The test circuit will be the same as that in Figure 1a, save that the B1 expression will be:

and the B2 expression will be the equivalent, or:

The intent is to determine if a signal with equivalent Boolean logic 1 and logic 0 voltage levels will be properly resolved by an ITE expression. The graph is shown in Figure 5a following:

Figure 5a
Ustep test circuit1 graph4

As may be seen, the ITE expression does recognize voltage levels as being equivalent to their boolean logic levels. The next question, is that if the input is offset from zero, what will happen? In Figure 6a following, the v1 generator has been changed to switch from 0.3 to 1.0 volts.

Here we see that the same ambiguity seems to be present in an ITE expression as in the ustep function. The help file notation for the ustep function (the 'u' operator) is:

The help file confirms the ambiguity for the ustep and uramp functions. Now for version 5, the preceding test as well as the version 5.1.6 release notes confirm that, within an ITE expression, the test condition must be the result of a logical expression (properly formed of course) OR equivalent to the 1/0 results of a logical expression.

There may be a seeming ambiguity in some logical operations using 'u' expressions. If two or more 'u' expressions are summed, the output is NOT a logical OR of the two 'u' expressions but an arithmetic sum of the output values of the 'u' expressions. Consequently, given functions f(a), f(b), ….f(z) where it is desired to get an output when any of these functions are greater than zero (or some threshold), it must be recognized that in this case one might get 26 different levels from the sum of the 'u' values for each expression.. Each non-zero level could represent different combinations of individual 'u' expressions. Consequently, in every case where 'u' expressions are summed to get a logical 'OR' output, an outer 'u' of this sum must be performed in order to get a unity multiplier for some output value.

Where 'u' expressions are multiplied, any single zero 'u' expression over an interval will 'blank' the overall product during that interval, and the overall product will be unity or zero, consequently a product of individual 'u' expressions (where these inner products are themselves corrected if they are the result sums of 'u' expressions) will be correct.

An Aside:

This corrected correction became apparent when. I was doing some writing for a project that hopefully will be finished at year's end.

The project involved using virtually all of the devices in the resources section, and in the process I noted some real errors aside from minor typographical errors, for which I blush. Several of the posted articles will have corrections shortly.