how to square convert to verilog.

J

Jack

Guest
hellow?

this is my c term.
i wnat to conver to verilog.

int i,j;
unsigned char * IMAGE;
int ResSquare;
IMAGE = new unsigned char [2048*1536];
for(j=0;j<1536;j++)
{
for(i=0;i<2048;i++)
{
ResSquare= (i-1024)*(i-1024)+(j-768)*(j-768);

if(ResSquare<=100*100)
IMAGE[i+j*2048]=255;
else
IMAGE[i+j*2048]=0;
}
}

how can i optimaze taht "ResSquare= (i-1024)*(i-1024)+(j-768)*(j-768);
".
 
Jack <love.theme@gmail.com> wrote:

< this is my c term.
< i wnat to conver to verilog.

That is fine, but you have to figure out what the algorithm
will look like in verilog. Normally it will be much different
than in a sequential language like C or C++.

(snip)

< ResSquare= (i-1024)*(i-1024)+(j-768)*(j-768);

< how can i optimaze taht "ResSquare= (i-1024)*(i-1024)+(j-768)*(j-768);

Until you have the rest of the algorithm converted, the question
doesn't make much sense. The usual reason for writing in verilog
is for speed, and that usually requires a parallel algorithm,
such as a systolic array. A serial algorithm in C isn't very
useful as an example, other than as a test to show that the
results are the same.

-- glen
 
On Sat, 4 Jul 2009 00:44:45 -0700 (PDT), Jack wrote:

this is my c term.
i wnat to conver to verilog.
[snip code]

That is a VERY expensive way to draw a circular blob,
of 100 pixels radius, in the centre of the screen.
(You did know that was what it does, I assume?
It would have been nice had you told us - my
geometry is not as slick it used to be; I had
to think about it for a minute or two.)

Instead, try looking-up Bresenham's circle drawing
algorithm. It's cheap, and maps easily to raster-
scan hardware scanning the image pixels in the
same order that your C code does. The usual form
of the algorithm draws a circular outline, but it's
easy to rework it to draw a filled circle like yours.

If you really, really want to do Pythagoras for
every pixel, then consider these useful facts:

1)
Much of the arithmetic can be pre-calculated.
For example, the term (j-768)*(j-768) remains
constant for an entire scan line and needs only
to be calculated once per 2048 points (something
the original C programmer has missed, and has
left to his compiler to optimize).

2)
For an 11-bit number 'i' in the range 0..2047,
the calculation (i-1024) is rather simple.
(j-768) is a little trickier, but still leaves
an awful lot of bits of j unchanged.
Alternatively, instead of running a loop from
0 to 1535 and subtracting 768 from every point,
how about running the loop from -768 to +767?

3)
As you move from one point to the next, you could
keep the previous value of i*i and use it to
compute (i+1)*(i+1) rather easily...

(i+1)*(i+1)
= i*i + 2*i + 1
= i*i + (2*i + 1)

Oooh, look, if I remember i*i I can get the next
value (i+1)*(i+1) just by adding something that's
quite easy to calculate....

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 

Welcome to EDABoard.com

Sponsor

Back
Top