FPGARelated.com
Forums
   Forums    More Forums    comp.arch.fpga  

How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?

Started by Mr. Ken ●May 30, 2006
Summary A designer seeking to implement a high-precision constant scaling factor of approximately 3.7097 for 9-bit signed data in an ASIC environment explores alternatives to simple power-of-two approximations.

A designer seeking to implement a high-precision constant scaling factor of approximately 3.7097 for 9-bit signed data in an ASIC environment explores alternatives to simple power-of-two approximations. The discussion focuses on balancing mathematical precision with hardware complexity, specifically comparing multipliers against shift-and-add logic.

  • Increasing the bit-depth of the multiplier is the primary recommendation for improving precision beyond the initial 0.599% error.
  • Using a ratio of larger integers, such as 3799/1024, allows for higher accuracy while maintaining a simple shift-based division.
  • A bit-serial approach is suggested as a method to minimize silicon area if the application can tolerate higher latency.
Fixed-Point ArithmeticASIC DesignDigital Signal Processing
My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
best precision possible. Without considering clipping and range issues, I
am using multiplication by 59/16, which gives 0.599% error. What better
approach can I use?

I am going to implement the calculation in ASIC, thus less complexity is
what I am expecting.
Reply by Peter Alfke ●May 30, 20062006-05-30
I assume your scaling factor is a constant, and your data is variable.
Now we need to know the available time for one conversion and also the
data rate (which can be significantly higher in a pipelined scheme).
In the digital realm, anything and everything is possible, if there is
enough time...
Peter Alfke, Xilinx
=========================
Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
>
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?
Reply by John_H ●May 31, 20062006-05-31
References: <447ceb61@news.starhub.net.sg>
In-Reply-To: <447ceb61@news.starhub.net.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <Ae8fg.9896$ho6.9329@trnddc07>
Date: Wed, 31 May 2006 03:40:16 GMT
NNTP-Posting-Host: 71.117.188.223
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1149046816 71.117.188.223 (Tue, 30 May 2006 23:40:16 EDT)
NNTP-Posting-Date: Tue, 30 May 2006 23:40:16 EDT

Mr. Ken wrote:

> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?