Re: How do you keep track of what all the numbers mean?
- From: "Rune Allnor" <allnor@xxxxxxxxxxxx>
- Date: 30 Jun 2006 21:16:01 -0700
Wilson wrote:
Rune Allnor wrote:
Wilson wrote:
I am looking for suggestions on tricks people use to keep track of what
all the fixed-point data values mean in their system. By this, I mean
that if you develop a floating point representation of a system, how do
you line up the signals and other values when you go to a fixed point
(i.e. hardware) representation of the model?
I haven't done any fixed-point programming myself, but the impression
I get from people who do, is that the main issue is to avoid overflow
and underflow. I can only guess as to how they achieve this,
but I would suspect that scaling constants is a main part of it.
For example, if I have a floating point simulation of a FIR filter,
when I implement this in hardware, it is done with integer data paths
and integer coefficients. The integer data will have a certain number
of data bits, and the coefficients may have different numbers of data
bits. There will be an assumed scaling between the floating point
representation and the fixed point representation. Are there a
procedures that you would suggest for how to keep track of these two
realms so that a meaningful relationship is maintained?
As another example, at the input of an ADC, you may have an arrangement
where the peak input of the ADC in 1 Volt. Does it make sense to
somehow keep track of this voltage scaling as you go through your
digital signal processing (in fixed point) so that you can line-up
different representations of the system in a meaningful way?
It depends on the application. There key term is "calibrated systems".
A "calibrated" system is one where you are supposed to measure
a physical quantity. A good example is the sound dB meter, where
absolute physical sound pressure is the key output. In this application
you need to keep track of all conversion constants, scalings etc.
In practice, the instrument must be calibrated every now and then.
A CD player, on the other hand, only needs to replicate the waveform
of the sound that was once recorded. Absolute sound pressure is
of less concern; the user adjusts the reproduced sound intensity
with the Volume knob anyway.
This is important because when you implement the system in hardware,
you want to make sure that the filter cutoff, loop bandwidths, etc. are
maintained amongst the theoretical / floating-point / hardware models.
All these factors are independent of scale, provided you stay inside
the dynamic range of the fixed point system.
I have tried to do things like this in the past, by keeping track of
the resolution of an LSB (as a voltage) but never been completely happy
with the usefulness of the effort.
In general, I'd say that there *are* applications where calibration is
needed. However, they are relatively rare so by and large, the
generalist DSP practisioner does not need to consider calibration
issues.
Rune
Rune,
Thanks for your comments. The issues I have stuggled with in the
past are in systems which have a feedback loops (e.g. LMS equalizers,
PLLs, etc.) In an LMS equalizer, for example, the convergence speed
will depend upon the input signal power.
Really? If so, these are non-linear systems. I would gues that
relative powers would be used, say, normaluze the excitation power
to 1, and then examine convergence rates.
So the stepsize of the LMS
algorithm that you arrive at in the floating point simulation will have
to somehow be related to the corresponding value in the fixed point
model. It's a little bit tricky to work through the different data and
coefficient scaling to ensure that the hardware stepsize matches the
floating point stepsize.
Tricky indeed...
I know there are different ways to interpret the data values (e.g.
fractional format vs. integer format). What I am looking for is some
way to represent the fixed point numbers in a way that makes it easy to
account for these different scaling values.
I would be surprised if you achieve that. Some years ago I operated
a signal measurement system, fixed point, 12 bit as far as I remember
(it could have been 10 or 14). The source was a pulsed source where
we only could control the timing, not the excited power.
I spent a lot of time adjusting the ADC's sensitivity. The software
allowed me to adjust the sensitivity in 50 mV steps between
+/-50 mV and +/-5V peak amplitude. For three weeks I sat 12 hours
per day, monitoring the data, adjusting the sensitivity of the system
to avoid overflow and at the same time exploiting the somewhat limited
dynamic range of the ADC.
Back in the lab, I started work on my precious, hard-earned data.
The first step was to find the normalizing constants so I could
scale the data from fixed-point representation to a floating-point
representation that also considered "true" amplitude.
Imagine my reaction when I found out that tyhe scaling constants
were never stored in the data files! The standard for the data file
format (the standard was 1973 vintage) specified that the scaling
constant should be stored as a power of two:
... 1/8, 1/4,1/2,1,2,4,8,...
and that's what had been stored. Not the nifty 50 mV steps.
Two months of planning and three weeks in front of the recording
station down the drain, just like that.
It has always seemed to me that the numbers we used in DSP are, in some
applications, less meaningful without the associated units that go with
them.
The numbers in _D_SP are just that; numbers. They don't mean
anything, they may -- but by no means need to -- represent
anything. DSP is maths. Applied maths.
So, in my LMS equalizer example, if my floating point equalizer input
has units of 'Volt' , but my fixed point equalizer input LSB
represents 1/1024 'Volt' then I know a data scaling relationship
between these two systems.
Sure. But you don't need the 'Volt' to find out that there is a
scaling factor of 1/1024 in your 10 bit ADC.
I am wondering if anyone has some suggestions for how to keep track of
the different data scales in systems like these.
Maths. If needed, store the scaling factors somewhere, as had not
been done in my files. If not needed, don't bother.
Rune
.
- References:
- Re: How do you keep track of what all the numbers mean?
- From: Rune Allnor
- Re: How do you keep track of what all the numbers mean?
- From: Wilson
- Re: How do you keep track of what all the numbers mean?
- Prev by Date: Re: How do you keep track of what all the numbers mean?
- Next by Date: Re: FFTs of FFTs
- Previous by thread: Re: How do you keep track of what all the numbers mean?
- Next by thread: Re: How do you keep track of what all the numbers mean?
- Index(es):
Relevant Pages
|
