How to create area-efficient comparator

R

rootz

Guest
I have a design which blows up significantly when I add a comparator
(sig_ans >`VALONE2). This is because the comparator is used several
times in a module and the module is also replicated several times. How
can I create a more efficient comparator ?

reg signed [63:0] sig_d3, sig_ans;
reg [63:0] val_3, res_3;
reg sig_dn3;
`define VALONE2 17'h10000

reg dne3;

always @ (posedge clk)
begin
if (sig_dn | (sig_ans >`VALONE2)) begin
sig_d3 = val_3 - res_3;
sig_dn3 = sig_d3[63];
end
else begin
sig_d3 = prev_2;
cdne3 = prev_dn2;
end
end
 
Since sig_ans is a 64-bit value, can you "compress" the top bits of this
value for an alternate comparison?
Rather than (sig_ans[63:0]>`VALONE2) you could have a register or (fewer
than 47) registers to provide the equivalent of

wire sig_ans_top0 = sig_ans[63:17]!=47'h0;

and have the resulting comparison be

if( sig_dn | sig_ans_top | (sig_ans[17:0]>`VALONE2) )

I've used the pipelining of the non-zero indication of the top bits (usually
compressed down to nibbles) in smaller comparisons with great results. Just
balance the two sides of the clock: the combinatorial results that make up
sig_ans before it's registered on the one side and the comparison width on
the other.



"rootz" <kgyang@gmail.com> wrote in message
news:1126045525.840236.143310@g47g2000cwa.googlegroups.com...
I have a design which blows up significantly when I add a comparator
(sig_ans >`VALONE2). This is because the comparator is used several
times in a module and the module is also replicated several times. How
can I create a more efficient comparator ?

reg signed [63:0] sig_d3, sig_ans;
reg [63:0] val_3, res_3;
reg sig_dn3;
`define VALONE2 17'h10000

reg dne3;

always @ (posedge clk)
begin
if (sig_dn | (sig_ans >`VALONE2)) begin
sig_d3 = val_3 - res_3;
sig_dn3 = sig_d3[63];
end
else begin
sig_d3 = prev_2;
cdne3 = prev_dn2;
end
end
Click to expand...
 
John_H wrote:
Since sig_ans is a 64-bit value, can you "compress" the top bits of this
value for an alternate comparison?
Rather than (sig_ans[63:0]>`VALONE2) you could have a register or (fewer
than 47) registers to provide the equivalent of

wire sig_ans_top0 = sig_ans[63:17]!=47'h0;

and have the resulting comparison be

if( sig_dn | sig_ans_top | (sig_ans[17:0]>`VALONE2) )

I've used the pipelining of the non-zero indication of the top bits (usually
compressed down to nibbles) in smaller comparisons with great results. Just
balance the two sides of the clock: the combinatorial results that make up
sig_ans before it's registered on the one side and the comparison width on
the other.


The problem with is is that sig_ans can be negative.

"rootz" <kgyang@gmail.com> wrote in message
news:1126045525.840236.143310@g47g2000cwa.googlegroups.com...
I have a design which blows up significantly when I add a comparator
(sig_ans >`VALONE2). This is because the comparator is used several
times in a module and the module is also replicated several times. How
can I create a more efficient comparator ?

reg signed [63:0] sig_d3, sig_ans;
reg [63:0] val_3, res_3;
reg sig_dn3;
`define VALONE2 17'h10000

reg dne3;

always @ (posedge clk)
begin
if (sig_dn | (sig_ans >`VALONE2)) begin
sig_d3 = val_3 - res_3;
sig_dn3 = sig_d3[63];
end
else begin
sig_d3 = prev_2;
cdne3 = prev_dn2;
end
end
Click to expand...
 
rootz wrote:
John_H wrote:

Since sig_ans is a 64-bit value, can you "compress" the top bits of this
value for an alternate comparison?
Rather than (sig_ans[63:0]>`VALONE2) you could have a register or (fewer
than 47) registers to provide the equivalent of

wire sig_ans_top = sig_ans[63:17]!=47'h0;

and have the resulting comparison be

if( sig_dn | sig_ans_top | (sig_ans[17:0]>`VALONE2) )

I've used the pipelining of the non-zero indication of the top bits (usually
compressed down to nibbles) in smaller comparisons with great results. Just
balance the two sides of the clock: the combinatorial results that make up
sig_ans before it's registered on the one side and the comparison width on
the other.



The problem with is is that sig_ans can be negative.
Click to expand...
<snip>

So if it's negative, the comparison is false. One bit.
The piped upper bits still work.
wire sig_ans_top0 = sig_ans[62:17]!=47'h0; // or piped-equivalent
if( sig_dn | ~sig_ans[63] & (sig_ans_top | (sig_ans[17:0]>`VALONE2) )
 
How about

wire sig_ans_top0 = sig_ans[62:17] != 47'h0; // or piped-equivalent

if( sig_dn | ~sig_ans[63] & (sig_ans_top | (sig_ans[17] &
|sig_ans[16:0]) )

No arithmetic comparison, so no arithmetic comparitor inferred.

PUT THE ORIGINAL CODE IN AS A COMMENT so that the next person
that looks at it can understand what you're doing!


John Providenza
 
Complaining? What's your issue? The previous post had the APPLICABLE CODE
from the discussion thread.

If you need the whole thing instead of just the line that was a problem,
look it up with groups.google.com.

There ARE complaints here when too much is included from the previous post
in the discussion thread. There are some archivers of this newsgroup who
prefer to keep the sizes reasonable. There are many ways to find the
information in the previous posts in the thread. Personally, I use a
threaded newsreader (grouped by discussion) and most newsgroup readers allow
tracing back up the discussion tree.

The original poster was doing 64-bit compares while only using the bottom 17
bits as "significant" where sig_ans apparantly can be negative. The post
you "complain" about that has no arithmatic comparator DOES an arithmatic
comparison, it just doesn't LOOK like it becuase I was showing the original
poster how to change the 64-bit compare.

Oh - and I'm top posting. Problem?


"johnp" <johnp3+nospam@probo.com> wrote in message
news:1126749038.764914.167030@f14g2000cwb.googlegroups.com...
How about

wire sig_ans_top0 = sig_ans[62:17] != 47'h0; // or piped-equivalent

if( sig_dn | ~sig_ans[63] & (sig_ans_top | (sig_ans[17] &
|sig_ans[16:0]) )

No arithmetic comparison, so no arithmetic comparitor inferred.

PUT THE ORIGINAL CODE IN AS A COMMENT so that the next person
that looks at it can understand what you're doing!


John Providenza
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top