FPGA Central

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" <[email protected]> wrote in message
news:[email protected] oups.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
>

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" <[email protected]> wrote in message
> news:[email protected] oups.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
> >

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.

<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" <[email protected]> wrote in message
news:[email protected] oups.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