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?
How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
Started by ●May 30, 2006
Reply by ●May 31, 20062006-05-31
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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?
