9
Fall 2011 EECS150 Lecture 18 Page 1 EECS150 - Digital Design Lecture 18 – Line Drawing Engine November 1, 2011 Elad Alon Electrical Engineering and Computer Sciences University of California, Berkeley http://www-inst.eecs.berkeley.edu/~cs150 Fall 2011 EECS150 Lecture 18 Page 2 Announcements Project checkpoint #3 due this week Checkpoint #4 due in two weeks Intermediate check point due in one week More details on the web soon

EECS150 - Digital Design Lecture 18 – Line Drawing Engineinst.eecs.berkeley.edu/~cs150/fa11/agenda/lec/lec18-linedraw.pdf · EECS150 - Digital Design Lecture 18 – Line Drawing

Embed Size (px)

Citation preview

Fall 2011 EECS150 Lecture 18 Page 1

EECS150 - Digital DesignLecture 18 – Line Drawing Engine

November 1, 2011

Elad AlonElectrical Engineering and Computer Sciences

University of California, Berkeley

http://www-inst.eecs.berkeley.edu/~cs150

Fall 2011 EECS150 Lecture 18 Page 2

Announcements• Project checkpoint #3 due this week

• Checkpoint #4 due in two weeks– Intermediate check point due in one week

– More details on the web soon

Fall 2011 EECS150 Lecture 18 Page 3

Project Notes• Offer: GSIs will be available to look at your code with you

today in office hours/lab

• Make sure you “check-off” even if your design isn’t fully functional– Note that in this case the only thing we can really give partial

credit for are your tests…

Fall 2011 EECS150 Lecture 18 Page 4

Modularity and Verification• You are dealing with a complex design

• You therefore need to decompose your design into “simple” sub-elements

• You also need to verify that each of these sub-elements works as desired– I.e., unit testing matters!

– And yes, writing the tests could easily take you twice (or more) as long as writing the module itself

Fall 2011 EECS150 Lecture 18 Page 5

Additional Project Tips• Use “make report” to look at the hardware you actually got

– In particular, double check that you got the latches you wanted (not any more or any less)

• Look at the block diagrams you drew– Make sure you understand how everything is working together

– And where the synchronous boundaries are

– Midterm problem #4 was there for a reason…

Fall 2011 EECS150 Lecture 18 Page 6

Midterm Problem 4 Review

AR1

RF

WE

AR2

WEAWDW

D1

D2

wclk

clk clk

AW

AR1

AR2

clk

Fall 2011 EECS150 Lecture 18 Page 7

Midterm Problem 4 Review

AR1

RF

WE

AR2

WEAWDW

D1

D2

wclk

clk clk

AW

AR1

AR2

clk

Fall 2011 EECS150 Lecture 18 Page 8

MIPS150 Video Subsystem

• Gives software ability to display information on screen.• Equivalent to standard graphics cards:• Processor can directly write the display bit map• 2D Graphics acceleration

Fall 2011 EECS150 Lecture 18 Page 9

Graphics Software

clear: # a0 holds 4-bit pixel color # t0 holds the pixel pointer ori $t0, $0, 0x8000 # top half of frame address sll $t0, $t0, 16 # form framebuffer beginning address # t2 holds the framebuffer max address ori $t2, $0, 768 # 768 rows sll $t2, $t2, 12 # * 1K pixels/row * 4 Bytes/address addu $t2, $t2, $t0 # form ending address addiu $t2, $t2, -4 # minus one word address# # the write loop

L0: sw $a0, 0($t0) # write the pixel bneq $t0, $t2, L0 # loop until done addiu $t0, $t0, 4 # bump pointerjr $ra

“Clearing” the screen - fill the entire screen with same color Remember Framebuffer base address: 0x8000_0000Size: 1024 x 768

How long does this take? What do we need to know to answer?How does this compare to the frame rate?

Fall 2011 EECS150 Lecture 18 Page 10

Optimized Clear Routineclear:

.

.

. # the write loop

L0: sw $a0, 0($t0) # write some pixels sw $a0, 4($t0) sw $a0, 8($t0) sw $a0, 12($t0) sw $a0, 16($t0) sw $a0, 20($t0) sw $a0, 24($t0) sw $a0, 28($t0) sw $a0, 32($t0) sw $a0, 36($t0) sw $a0, 40($t0) sw $a0, 44($t0) sw $a0, 48($t0) sw $a0, 52($t0) sw $a0, 56($t0) sw $a0, 60($t0) bneq $t0, $t2, L0 # loop until done addiu $t0, $t0, 64 # bump pointer jr $ra0

What’s the performance of this one?

Amortizing the loop overhead.

Fall 2011 EECS150 Lecture 18 Page 11

Line Drawing

Fall 2011 EECS150 Lecture 18 Page 12

Bresenham Line Drawing Algorithm

• Computers of the day, slow at complex arithmetic operations, such as multiply, especially on floating point numbers.

• Bresenham’s algorithm works with integers and without multiply or divide.

• Simplicity makes it appropriate for inexpensive hardware implementation.

• With extension, can be used for drawing circles.

Developed by Jack E. Bresenham in 1962 at IBM. "I was working in the computation lab at IBM's San Jose development lab. A Calcomp plotter had been attached to an IBM 1401 via the 1407 typewriter console. …”

Fall 2011 EECS150 Lecture 18 Page 13

Line Drawing Algorithm

Fall 2011 EECS150 Lecture 18 Page 14

Line Drawing, Examplesdeltay = 1 (very low slope). y only gets incremented once (halfway between x0 and x1)

deltay = deltax (45 degrees, max slope). y gets incremented for every x

Fall 2011 EECS150 Lecture 18 Page 15

Line Drawing Example

Fall 2011 EECS150 Lecture 18 Page 16

C Version

Modified to work in any quadrant and for any slope.

What’s needed to do it in hardware?

Goal is one pixel per cycle. Pipelining might be necessary.

Fall 2011 EECS150 Lecture 18 Page 17

Hardware Implementation Notes

x0

y1x1

0

32

0x8040_0040:0x8040_0044:

0x8040_0064:Read-only control register ready0x8040_0060: color

y0

10

x0

x1

y0

0x8040_0048:0x8040_004c:0x8040_0050:0x8040_0054:0x8040_0058:0x8040_005c:

Write-only trigger registers

Write-only non-trigger registers

• CPU initializes line engine by sending pair of points and color value to use. Writes to 0x8040_005* trigger engine.

• Framebuffer has one write port - Shared by CPU and line engine. Priority to CPU - Line engine stalls when CPU writes.

y1