[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