Picture Model

Picuture Model (PM) was a resolution-independent image description language devised by Bill Mills and others in Teklabs. I designed and fabricated a PM rasterizer by unwrapping the computation into a two dimensional systolic array of point-sample machines.

PM used second-order polynomials in x, y as graphic primitives. The sign of an expression would specify a region of space, the value would be used to color it.

ax2 + by2 + cx + dy + e

A series of shapes defined by the coefficients a, b, c, d and e would be combined with union and intersection to produce a mask that would then be applied to an RGB gradient defined by three more sets of coefficients. This would repeat to paint an image.

Bill had created a text front end for his own implementation using m4 macros. I was eager to give it a try. I translated stats from my Radio Network Simulator into hyperbolic bubbles for each city over a grid of route lines. I made bubble size represent backlog and color represent throughput. I used a thermal scale for color running from red to yellow by varying the green component of RGB. Mike Rieger (Bill's boss) liked it but asked why I was so tame in my color selection.


Bill noted that the polynomials could be evaluated incrementally over time by finite difference methods using only adders. He suggested a machine be built with a queue of coefficients circulating through a traditional ALU. wikipedia

I was stunned by this book which I read in a weekend. Lynn Conway recalls its creation. pdf

I recast Bill's machine as a network of ALUs wired to do exactly the needed calculation. I used a programmed logic array (PLA) to realize the state machine needed to switch output summers on and off based on the signs of previous results. My scheme was to flow coefficients through a 10 x 10 array to get one super-sampled pixel out 20n cycles later.

I used bit-serial ALUs so that coefficients could be as large as necessary for the spatial resolution desired. Keith Lofstrom criticized the design pointing out that I would spend more time in latches than computing in my ALUs. A simple fix would be to compute with nibble wide ALUs where the nibble size would be optimized to balance carry propagation with latch speeds.

I simulated the complete design with MIT's Switch Level Simulator. The version I used had a small lisp driver so I wrote lisp code to sequence coefficients through the design. I also captured vectors at all the pins to use later for testing silicon.

I did the physical design with Tom Almy's hierarchal layout system written in Forth and run on his Radio Shack TRS-80. This worked surprisingly well. Whenever it didn't work well I just told Tom that Forth wasn't very good for IC layout and he would work all evening building Forth words to make my job easy.

I got six parts back from MOSIS fabrication. The first one I tested didn't work. What now? A fellow from our IC group suggested holding phase 1 and 2 clock lines high and test the combinatorial behavior of the parts at dc. It still didn't work. I tried the other parts. They did work. And they worked at speed too.

I made two mistakes promoting this work.

Although I could generate any size part, and the recommended 10x10 easily fit in the MOSIS process, I chose to test 4X4 and leave room on the dies for other projects. My transistor count thus failed to impress.

Rieger's group was ready to build my parts into their super flexible frame buffer design. They asked me how to approach it. My first thought was to design another VLSI interface chip. This made me the bottle neck and left nothing for their hardware guy to do. I should have just handed them the good parts.

I was ready to make a 10x10 part and include a raised cosine anti-aliasing kernel in the computation. I could do this with just a few more adders in each position since the cosine would be constant there and satisfactory implemented with a few shifts and adds. wikipedia


Bill took the VLSI class that my boss, Kit Bradly, taught at OGC. He made a version of his queue'd architecture by reducing the queue size to one, a single set of coefficient registers. This could render one shape at video rates. He called it the Conic Cursor.

I had a go at this years later when I was looking for something fun to do with video. I evaluated a single set of coefficients with 8-bit arithmetic which overflowed in nice ways if one wanted a kaleidoscope. I dubbed this Video Circles and showed one version in an art gallery.

Circles are useful when aligning HDTV projectors. Lee Jalovec once asked me if I knew a good way to draw circles. Yes I did. We coded up the ALUs in verilog and ran it on his prototype test pattern generator. It worked, at HD bit rates too, but used the better part of an expensive part so this never made it into their product.