D, F, G, H, I, K have multiple clocks, so A, B, C, E, J do not. Since A does not work and C is a joke this leaves B, E, and J as my best examples.

space and time language for laying out datapath, no automatic binding of operations to operators, interdigitate 10 bit paths.

Write an abstract position paper that talks about the systems aspects of using a softhardware board on a sun. Talk about swapping virtual machines to disk. Connection across backplane bus to RAM via DMA. Applications such as ATMS, binary image manipulation for scanning and printing, encryption and compression. Reduction of algorithms by a factor of n. Point out that rates achievable now for those applications may not make sense commercially because of other weak links in the system but will make sense as these others evolve.

Perhaps a new RAM tile that uses the same address bits for read and write and removes the read enable. The read data is always the addressed location. Then some other method for ganging the tiles vertically must be invented. Also think about using long lines for read/write data.

Consider doubling the number of LeftUp and RightDown lines. Look at programmings to determine the interconnect corner to straight ratio. If it is low then adding only straight lines helps, otherwise both corners and straight lines are needed.

People could be working on:

Work is divided into:

"Programmable Logic: Architecture and Applications"

"Hardware Without Tears"

This report discusses a model of computation which is radically different from what has become known as the von Neumann architecture. It is different in the means of communication between logical elements and the granularity of the logical elements available to the programmer. It exploits late binding to an extraordinary degree. Philosophically, it is closer to the Connection Machine [Hillis] than to a traditional von Neumann machine. However, the sequencing mechanism is much different from a Connection Machine. It also has roots in VLIW architectures [?]. The programmable gate arrays of [Xilinx] provided the initial guide to this marriage of technology and architecture. The Xilinx literature views this marriage as between technology and traditional logic design. In this report we expand this view to encompass descriptions closer to parallel programming languages, as well as logic design.

The report proceeds as follows. Chapter 2 discusses architectural philosophy. In it we look at history, seeking a philosophical basis for the architecture. We study the primitive elements which have been useful for hardware implementation. We study applications, and the underlying algorithms which have been used to implement them. Finally we look at the underlying technology, seeking understanding of the computational structures which it implements well.

Chapter 3 proposes a specific architecture. It describes the programming abstraction, similiar to the principles of operation of a von Newmann machine. We do not forsake the von Neumann architecture completely. Our architecture is embedded in an existing commercial workstation. We give programming examples which illustrate the implementation of traditional logic structures.

Chapter 4 describes the utilization of this architecture as a logic emulation machine. We lay out the design automation tools required and the interface of the architecture to existing components. A commercial realization of this architecture using the Xilinx Programmable Gate Arrays is already available [QuickTurn]. We contrast the range of applications which the two designs can handle.

Chapter 5 turns to 2.5D rasterization as an application. Here we study the rendering of planar images with overlap. We talk about system architectures which embed programmable logic as a rasterization engine. The rendering of different types of graphical objects, such as rectangles and character glyphs, is discussed. High quality raster print engines and interactive display devices are the major subareas, each is given a section.

Finally, chapter 6 takes a critical look at the architecture, refining the boundary seperating applications which match this architecture and those that do not. We also wave our hands at a number of applications which seem particularly well suited to the architecture.

It is possible that the existing Xilinx chips, combined with standard commercial RAMs are adequate for this task. One problem with them is the long period of time it takes to reprogram them through their serial port. The Xilinx design handbook indicates that the load time varies between 12ms and 24 ms. This is almost an entire frame time for a display output device. So you could use Xilinx chips for prototyping by glitching the display on every change, or do it glitch free by ping ponging completely replicated hardware. Another problem with them is the limited amount of memory within them. This makes a very deeply pipelined design quite difficult. These chips also waste a tremendous amount of space on interconnect options.

Look at Spreitzer's encoding of the screen.

Think about the relationship between the width of a text object and the size of the alignment network to put the pixels from font storage into the chunk.

The object types should be parameterized by the number of pixels they deal with at once. This allows the bandwidth to be scaled without rewriting the object types.

Of course the position of the object and the position of the window can, conceptually at least, be bound when the object is generated.

For now let's assume that the object and window are rectangles. They are obviously rectilinear since this machine is working at the pixel level.

We must decide where clipping things to the screen will occur. This determines the range necessary for specifying coordinate positions. To within a chunk the position in which an object is emitted is determined by the clock cycle in which the object starts emitting its pixels. In this way objects which lie off the screen will either never be generated, because vertical sync starts the object over, or the bits for the object... I think the answer is that the host can clip objects if it needs to in order to not overflow the resources in the soft hardware. If it doesn't bother then the machines programmed into the array are smart enough to clip properly. This mostly means that they know how to start generating pixels someplace in the interior of an object, rather than always starting at the object origin.

Another way to increase bandwidth is to make the chunks into bands, i.e. more than one pixel high. Then it is the job of the serializer to store the additional scan lines and play them out when the time comes.

For a line object we need a single point in addition to the generic information which every object must have. For a line parallel to the axis we merely need a bit specifying which axis and another number which is the length of the line. This is for single pixel lines. Lines with width are really rectangles.

There are several cases for a simple line.