October 9, 1997

Correction and updates

In "New IC packages really pack in the leads" (EDN, Sept 1, 1997, pg 93), Table A on pg 98 is missing the manufacturers' column. The corrected table is below. EDN regrets the error.

In "Taming the Universal Serial Bus" (EDN, June 19, 1997, pg 61), Nohau Corp was inadvertently omitted from Table 1 and the list of manufacturers. Nohau supports the USB with its EMUL251-PC emulator for the 829-30AX. The contact information is:

Nohau Corp
Campbell, CA
1-408-866-1820
fax 1-408-378-7869
www.nohau.com

In "Give DACs due diligence for superior DDS performance" (EDN, July 17, 1997, pg 59), spurious-free dynamic range (SFDR) is incorrectly defined as the difference in signal energy between the desired fundamental output and the worst-case spurs. SFDR is actually a log ratio of signal energies--the difference between the logs of the fundamental and the biggest spurs.

Definition clarification

What triggered my letter are the definitions of "rapid prototyping" and "hardware in the loop" in "Electromechanical simulation: Tackling control systems takes talent and tools" (EDN, Aug 1, 1997, pg 83). Such terms are not standardized and are indeed used with different meanings sometimes. The most common definitions, however, differ from Dan Strassberg's.

In rapid control prototyping, the real system to be controlled is controlled by a real-time simulation of the controller. The processor is running floating-point arithmetic, is much faster, and has more memory than the production processor. I/O is flexible and faster and has more resolution. The higher performance and the floating-point arithmetic (maybe even double precision) are necessary to accommodate the inefficiencies that the convenience of graphical front ends (block diagrams, etc) and automatic code generation brings, as well as to allow creative controller design without being hampered by resources in this early stage of prototyping.

The above definition is different from Strassberg's because he assumed that the real controller does the work. That arrangement, however, usually does not allow for really rapid prototyping because of the lack of resources. Also, if the controller hardware is not yet available and has to be developed, controller testing could start only after a working and usable hardware prototype exists, which lengthens development time.

In hardware-in-the-loop simulation, the controller (the electronic control unit, or ECU) exists at least as a working prototype and is tested against a simulated replica of the system to be controlled. That replica runs a mathematical model of the real system on a real-time computer and simulates the system reactions in a closed loop. An example is the test of an engine-control ECU. Nowadays, such ECUs have some 50% of the code dedicated to diagnostics. Proper sensor signals are then required in reaction to the ECU's actuator outputs, because if the ECU detects unreasonable signals, it switches to emergency mode, making the testing of most of the ECU's software functions impossible. The proper reaction to ECU outputs can be achieved only by a model of the engine operated in a closed loop with the ECU.

Herbert Hanselmann
President/CEO
dSpace GmbH
Paderborn, Germany

graphical front ends (block diagrams, etc) and automatic code generation brings, as well as to allow creative controller design without being hampered by resources in this early stage of prototyping.

The above definition is different from Strassberg's because he assumed the real controller does the work. That arrangement, however, usually does not allow for really rapid prototyping because of the lack of resources. Also, if the controller hardware is not yet available and has to be developed, controller testing could start only after a working and usable hardware prototype exists, which lengthens development time.

In hardware-in-the-loop simulation, the controller (the electronic control unit, or ECU) exists at least as a working prototype and is tested against a simulated replica of the system to be controlled. That replica runs a mathematical model of the real system on a real-time computer and simulates the system reactions in a closed loop. An example is the test of an engine-control ECU. Nowadays, such ECUs have some 50% of the code dedicated to diagnostics. Proper sensor signals are then required in reaction to the ECU's actuator outputs, because if the ECU detects unreasonable signals, it switches to emergency mode, making the testing of most of the ECU's software functions impossible. The proper reaction to ECU outputs can be achieved only by a model of the engine operated in a closed loop with the ECU.

Herbert Hanselmann
President/CEO
dSpace GmbH
Paderborn, Germany

Division by 10

Richard Sheldon lamented in Signals & Noise ("No fear of binary multiplication," EDN Europe, August 1997) that division by 10 was proving to be a stumbling block in his conversion of 64-bit binary numbers to ASCII decimal numbers. Such conversion is much easier if one converts the input number to a fraction first and then converts the fraction to decimal, starting with the most significant digit.

In Sheldon's case, this approach can be accomplished by multiplying by 1.D83C_94FB_6D2A_C34A (in hexadecimal). (This value is (2⁶⁴)/(10¹⁹).) The overflow digit from the multiplication is the most significant digit of the output. (The overflow is the integer part of (result/(2⁶⁴)).) To get each succeeding digit, multiply by 10. (The "overflow" is the output digit.) After 19 such multiplications, all 20 digits of the result have been output. The most significant digit is the first one out; the least significant digit is the last one produced by this algorithm.

To preserve accuracy, some care must be taken with the low-order 64 bits of the 128 (or so) resulting from the initial multiplication. I haven't worked out the requirements for Sheldon's application, but in my own application I keep a few "guard bits" on the low end in addition to the bits that are really of interest. After the first multiplication by 10, the need for those guard bits disappears. It may work out that rounding the result of the initial multiplication is sufficient to maintain accuracy and that no additional guard bits are necessary.

This process can be faster than repeated division, because multiplication is generally faster than division. The trade-off is that the intermediate results require manipulation of numbers slightly longer (that is, having more bits) than the number being converted.

If the 64-bit number represents a scaled engineering value, any required scaling factors can be folded into the initial multiplication factor. In addition, tricks can be played with that scale factor (for example, dividing it by 16) so there is no overflow, and output can be taken as the highest order nibble of the intermediate product or products. In general, guard bits are necessary to maintain 64-bit accuracy in these cases.

Larry Morris
via the Internet

Conversion of an integer from one base to another is simply one of evaluating the implied polynomial using the target arithmetic. Because a polynomial implies multiplication, division is never required.

An n-digit number in position notation is written as the n-tuple N:b_n­1...b₁b₀ and has the value in base b of

V(N)=b_n­1b^n­1+ ... b₁b+b₀= (((...(b_n­1)b+b_n­2)b+...)b+b₁)b+b₀.

This form is called Horner's form, or method.

Sheldon uses this form to convert from decimal to binary when b=10, the target arithmetic is binary, and the method is "multiply and add" using binary arithmetic. The mathematics is independent of the source and target bases and applies equally to conversion from binary to decimal and from decimal to binary, negating any need for division. In fact, the conversion from binary to decimal is somewhat simpler because the multiplier (base) is 2 (one can use a shift left or add to self), and the subsequent add of the next bit cannot generate a carry.

The only problem is how to perform decimal arithmetic with a binary computer. This problem is solved in many computers by the provision of a DAA (decimal-add-adjust) command that may be used after the multiply by 2 is done with an add-to-self technique. The PIC16C5x µPs do not have a DAA command; instead, they use a method of preconditioning the partial result to force a decimal multiply by 2 as a left shift (see Microchip application note AN526 or AN544).

Bob Jackson
CCDA Inc
Rolling Hills Estates, CA

Sound off

"Signals & Noise" lets you express your opinions on issues raised in the magazine's articles or on any engineering-related topic. Send your letters to Signals and Noise Editor, EDN, 275 Washington St, Newton, MA 02158 or e-mail us at bmorrison@edn.cahners.com. Our fax is 1-617-558-4470. EDN reserves the right to edit letters for clarity and length.

| EDN Access | Feedback | Table of Contents |