[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: OT: Opencores CORDIC - bugs?



On Fri, 2007-03-09 at 20:51 -0800, Ben Jackson wrote:
> On Sat, Mar 10, 2007 at 04:14:19AM +0000, Peter Clifton wrote:
> > 
> > In twos complement - for the specific implementation used at least -
> > which sign extends with the original MSB:
> > 
> > 	-2 >> 1 == -1
> > 	-1 >> 1 == -1
> > 	      (etc..)
> > 
> > Clearly this is different from the behaviour for +ve numbers, hence he
> > discrepency I noted.
> 
> Verilog won't sign-extend with >>, you'd want to use >>>.  If you are
> expecting arithmetic right shift and getting logical left shift, you'd
> get totally different results.  If you're sure you're getting arithmetic
> shift, and you don't like the rouding, you will have to do something
> about it.  The easiest thing would be to add in the MSB (1 for -ve)
> first.  So instead of (x >>> 1) you'd have ((x + x[msb]) >>> 1).  That
> will not change the result for positive (msb = 0) but will fix the
> rounding for negative x.

Thanks for the hit on the syntax. The Opencores implementation doesn't
use >> or >>>, it expands a for-loop to replace the bits individually.

It also sounds like the workaround is a lot less expensive than my own.
I'm not clear what the hardware synthesis would generate, but I'll try
it under ghdl.

As there are a number of these pipelines, it might just pay to keep in
the +ve quadrant / octant on these, and introduce more complexity in the
pre / post processing.

Thanks,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user