FPGA Central

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.

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.

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?

References: <[email protected]>
In-Reply-To: <[email protected]>
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: [email protected]
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?