Fixed Point Arithmetic...

[gnuarm.del...@gmail.com]

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[gtwrek]

In article <d7d24872-8ed4-4d5f-96a5-645a05254799n@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Regards,
Mark

 

[gtwrek]

In article <d7d24872-8ed4-4d5f-96a5-645a05254799n@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Regards,
Mark

 

[gtwrek]

In article <d7d24872-8ed4-4d5f-96a5-645a05254799n@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Regards,
Mark

 

[gtwrek]

In article <d7d24872-8ed4-4d5f-96a5-645a05254799n@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Regards,
Mark

 

[gnuarm.del...@gmail.com]

On Tuesday, December 29, 2020 at 4:45:38 PM UTC-5, gtwrek wrote:

In article <d7d24872-8ed4-4d5f...@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?
If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

There\'s no IIR sections. No filtering really... yet. Some of the inputs are from ADC built into the FPGA with large integrators otherwise known as counters. Simple, but effective at eliminating noise, so no need for additional filtering.

The calculations are more along the line of compensating for offset and scale factor, a few require calculations. Actually, one is an integrator, turning flow rate into volume, but the range of that one is determined and overflow avoided.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

Yeah, the reason for using the FPGA is the thinking that the \"hardware\" design will not be as hard to get through approvals as software. lol Not my idea, but I\'m willing to help.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

The requirements are not stringent, but the multipliers have 18 bits. Extending that uses a lot more resources and becomes more complex.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Floating point would seem to be overkill. There\'s not enough calculations to worry with numerical error if using floating point. Still, I\'m not looking for that... I think. It would be interesting... I wish you hadn\'t mentioned it. lol

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[gnuarm.del...@gmail.com]

On Tuesday, December 29, 2020 at 4:45:38 PM UTC-5, gtwrek wrote:

In article <d7d24872-8ed4-4d5f...@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?
If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

There\'s no IIR sections. No filtering really... yet. Some of the inputs are from ADC built into the FPGA with large integrators otherwise known as counters. Simple, but effective at eliminating noise, so no need for additional filtering.

The calculations are more along the line of compensating for offset and scale factor, a few require calculations. Actually, one is an integrator, turning flow rate into volume, but the range of that one is determined and overflow avoided.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

Yeah, the reason for using the FPGA is the thinking that the \"hardware\" design will not be as hard to get through approvals as software. lol Not my idea, but I\'m willing to help.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

The requirements are not stringent, but the multipliers have 18 bits. Extending that uses a lot more resources and becomes more complex.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Floating point would seem to be overkill. There\'s not enough calculations to worry with numerical error if using floating point. Still, I\'m not looking for that... I think. It would be interesting... I wish you hadn\'t mentioned it. lol

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[gnuarm.del...@gmail.com]

On Tuesday, December 29, 2020 at 4:45:38 PM UTC-5, gtwrek wrote:

In article <d7d24872-8ed4-4d5f...@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?
If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

There\'s no IIR sections. No filtering really... yet. Some of the inputs are from ADC built into the FPGA with large integrators otherwise known as counters. Simple, but effective at eliminating noise, so no need for additional filtering.

The calculations are more along the line of compensating for offset and scale factor, a few require calculations. Actually, one is an integrator, turning flow rate into volume, but the range of that one is determined and overflow avoided.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

Yeah, the reason for using the FPGA is the thinking that the \"hardware\" design will not be as hard to get through approvals as software. lol Not my idea, but I\'m willing to help.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

The requirements are not stringent, but the multipliers have 18 bits. Extending that uses a lot more resources and becomes more complex.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Floating point would seem to be overkill. There\'s not enough calculations to worry with numerical error if using floating point. Still, I\'m not looking for that... I think. It would be interesting... I wish you hadn\'t mentioned it. lol

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[gnuarm.del...@gmail.com]

On Tuesday, December 29, 2020 at 4:45:38 PM UTC-5, gtwrek wrote:

In article <d7d24872-8ed4-4d5f...@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?
If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

There\'s no IIR sections. No filtering really... yet. Some of the inputs are from ADC built into the FPGA with large integrators otherwise known as counters. Simple, but effective at eliminating noise, so no need for additional filtering.

The calculations are more along the line of compensating for offset and scale factor, a few require calculations. Actually, one is an integrator, turning flow rate into volume, but the range of that one is determined and overflow avoided.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

Yeah, the reason for using the FPGA is the thinking that the \"hardware\" design will not be as hard to get through approvals as software. lol Not my idea, but I\'m willing to help.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

The requirements are not stringent, but the multipliers have 18 bits. Extending that uses a lot more resources and becomes more complex.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Floating point would seem to be overkill. There\'s not enough calculations to worry with numerical error if using floating point. Still, I\'m not looking for that... I think. It would be interesting... I wish you hadn\'t mentioned it. lol

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[gnuarm.del...@gmail.com]

On Tuesday, December 29, 2020 at 4:45:38 PM UTC-5, gtwrek wrote:

In article <d7d24872-8ed4-4d5f...@googlegroups.com>,
gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results
don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when
it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job
just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest
amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of
0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?
If your algorithm is entirely \"feed forward\" (think like FIR filter) then it\'s easy.
Just compute the max numeric range at each step, and keep enough bits to
never allow overflow. For the FPGA/ASIC designs I\'ve done 90% of my
designs fit here.

If your algorithm has feedback ( i.e. like IIR ), then it gets a bit more
complicated. You need to put a rounding/truncation/saturation bit-reduction stage
in somewhere. Carry enough bits for as long as you can, then explcitly add this
bit-reduction stage.

There\'s no IIR sections. No filtering really... yet. Some of the inputs are from ADC built into the FPGA with large integrators otherwise known as counters. Simple, but effective at eliminating noise, so no need for additional filtering.

The calculations are more along the line of compensating for offset and scale factor, a few require calculations. Actually, one is an integrator, turning flow rate into volume, but the range of that one is determined and overflow avoided.

The design (and placement in the processing chain ) of the this bit reduction
block is very system dependent. For me, it\'s often best to punt
some of this tuning to software, instead of always getting it perfect,
the first time in hardware. At the bit-reduction stage include the ability
for software to adjust the range by a a few bits - you shouldn\'t need
anything near approaching a full-on IEEE dynamic floating point. I\'ve only
ever needed 2-3 bits of range control. Feed the software a
saturation/overlow indicator from this bit-reduction block to help tune.

If you\'re entirely hardware, without software in the loop - your
problem becomes even a bit harder.

Yeah, the reason for using the FPGA is the thinking that the \"hardware\" design will not be as hard to get through approvals as software. lol Not my idea, but I\'m willing to help.

In general, however, with todays FPGAs, it\'s usually much cheaper to err
on the side of just adding more bits of resolution to give yourself more
margin.

The requirements are not stringent, but the multipliers have 18 bits. Extending that uses a lot more resources and becomes more complex.

Or you can truly punt (like far too many folks dipping their toes in
FPGA design) and decide you need floating point everywhere - and
horribly overdesign, and consume resources left and right! (And still
have rounding/truncation/saturation issues, but just not be aware of it
on the onset..)

Floating point would seem to be overkill. There\'s not enough calculations to worry with numerical error if using floating point. Still, I\'m not looking for that... I think. It would be interesting... I wish you hadn\'t mentioned it. lol

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[David Brown]

On 29/12/2020 21:25, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If you are trying to get accurate results near zero despite noise and
variation, you want signed types. Saturating at zero is,
mathematically, a rather arbitrary point even though it can be
convenient in the implementation. Wrapping at zero is far worse. So
use signed Q1.17 (-1.0 to +1.0) or if you need more range, signed Q2.16
(-2.0 to +2.0). In theory, you could have an asymmetric type with a
range -0.5 to +1.5, but that\'s more complicated.

 

[David Brown]

On 29/12/2020 21:25, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If you are trying to get accurate results near zero despite noise and
variation, you want signed types. Saturating at zero is,
mathematically, a rather arbitrary point even though it can be
convenient in the implementation. Wrapping at zero is far worse. So
use signed Q1.17 (-1.0 to +1.0) or if you need more range, signed Q2.16
(-2.0 to +2.0). In theory, you could have an asymmetric type with a
range -0.5 to +1.5, but that\'s more complicated.

 

[David Brown]

On 29/12/2020 21:25, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If you are trying to get accurate results near zero despite noise and
variation, you want signed types. Saturating at zero is,
mathematically, a rather arbitrary point even though it can be
convenient in the implementation. Wrapping at zero is far worse. So
use signed Q1.17 (-1.0 to +1.0) or if you need more range, signed Q2.16
(-2.0 to +2.0). In theory, you could have an asymmetric type with a
range -0.5 to +1.5, but that\'s more complicated.

 

[David Brown]

On 29/12/2020 21:25, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

If you are trying to get accurate results near zero despite noise and
variation, you want signed types. Saturating at zero is,
mathematically, a rather arbitrary point even though it can be
convenient in the implementation. Wrapping at zero is far worse. So
use signed Q1.17 (-1.0 to +1.0) or if you need more range, signed Q2.16
(-2.0 to +2.0). In theory, you could have an asymmetric type with a
range -0.5 to +1.5, but that\'s more complicated.

 

[Kevin Neilson]

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

 

[Kevin Neilson]

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

 

[Kevin Neilson]

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

 

[Kevin Neilson]

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:

I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

 

[gnuarm.del...@gmail.com]

On Wednesday, December 30, 2020 at 12:05:37 PM UTC-5, Kevin Neilson wrote:

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets.. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

Should not be using hardware??? What a curious thing to say. So the calculations should be done by the user in their heads? Radical! I\'ll have to get that into the requirements.

Yes, it is a block similar to the DSP48, but I see no mechanism to provide saturating arithmetic. It is an 18x18 multiplier (or two depending on configuration) and a three input adder/subtractor (configuration choice, not real time darn it). One of the three adder inputs can be the output to make it an accumulator.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[gnuarm.del...@gmail.com]

On Wednesday, December 30, 2020 at 12:05:37 PM UTC-5, Kevin Neilson wrote:

On Tuesday, December 29, 2020 at 1:25:37 PM UTC-7, gnuarm.del...@gmail.com wrote:
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.

I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.

The saturating arithmetic seems to be required when subtracting offsets.. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.

Anyone have advice about all this?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
If you are using VHDL, which I think you are, there is a good, synthesizable (standardized, I believe) fixed-point library which handles saturation and other modes and makes tracking the radix points easier. I used it once years ago and was happy with it. I haven\'t done any fixed-point in several years since I mostly do finite fields now. If you are using something like the DSP48 blocks in a Xilinx, remember there are hardware structures to handle saturation and rounding which let you operate at full speed. If this is the project you\'ve mentioned before, though, with very slow processing rates, you oughtn\'t to be using hardware. I know you mentioned some rationale below, but nonetheless, anything that doesn\'t need to do gigaoperations per second is ten times easier to design in C using floating-point.

Should not be using hardware??? What a curious thing to say. So the calculations should be done by the user in their heads? Radical! I\'ll have to get that into the requirements.

Yes, it is a block similar to the DSP48, but I see no mechanism to provide saturating arithmetic. It is an 18x18 multiplier (or two depending on configuration) and a three input adder/subtractor (configuration choice, not real time darn it). One of the three adder inputs can be the output to make it an accumulator.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209