The small headache relates to the best way to describe complex combinatorial logic that doesn’t involve any registers. Consider some hypothetical logic that determines the value of the incrementPC and loadA control signals, based on the current state. One way to do this would be:

    wire incrementPC, loadA;
    assign incrementPC = (state == s1) || (state == s3) || (state == s4);
    assign loadA = (state == s0) || (state == s2) || (state == s4);

That works fine, and it’s pretty clear what it does. But for more complex designs, it’s clearer to use procedural assignment and a case statement, grouping all of the control signals for each state together:

    reg incrementPC, loadA;
    always @* begin
        case (state)
            s0:
                incrementPC = 1'b0;
                loadA = 1'b1;
                // other control signals...
            s1:
                incrementPC = 1'b1;
                loadA = 1'b0;
                // other control signals...
            s2:
                incrementPC = 1'b0;
                loadA = 1'b1;
                // other control signals...
            s3:
                incrementPC = 1'b1;
                loadA = 1'b0;
                // other control signals...
            s4:
                incrementPC = 1'b1;
                loadA = 1'b1;
                // other control signals...
        endcase
    end

The problem with this approach is visible in the first line: incrementPC and loadA must be declared as type “reg”, even though they are not registers. During synthesis, no register will be created as long as your code is correct, but Verilog demands that the target of a procedural assignment like this always be type “reg”. So reg does not always mean that something is a register. I find this very confusing and misleading, because it means you can’t just look at the Verilog code to see which signals are registers and which are purely combinatorial.

My bigger problem is more subtle, and is about good HDL design practices rather than any quirk of the Verilog standard. I’m unsure how explicit I should be in defining the structure of the virtual hardware described by the Verilog code. At one extreme, I could write a high-level functional description of *what* the CPU does, ignoring *how* it does it, and leave the Synthesis software to figure it out. Or at the other extreme, I could work out a block diagram of the CPU consisting of familiar real-world elements like registers, arithmetic unit, muxes, and busses, and then write Verilog code to describe these elements and how they’re all connected.

To help make this distinction clearer, here’s an example based on section 6.2.4 of the book FPGA Prototyping by Verilog Examples. Imagine a state-driven system that can add two input registers, and store the output in a third register. One way to describe this would be high-level, functional:


    always @(posedge clk) begin
        case (state)
            s0:
                d0 <= a + b;
            s1:
                d1 <= b + c;
            s2:
                d2 <= a + c;
        endcase
    end
    


Great, that’s compact and clear. But what does the datapath of this hardware look like? Is there one adder unit, or three? Who knows? It’s a black box, relying entirely on the synthesis software to do the right thing.

A second approach would be to explicitly define a single adder unit:


    assign mout = in1 + in2;
    
    always @* begin
        // default: maintain same values
        d0_next = d0;
        d1_next = d1;
        d2_next = d2;
        
        case (state)
            s0:
                begin
                    in1 = a;
                    in2 = b;
                    d0_next = mout;
                end
            s1:
                begin
                    in1 = b;
                    in2 = c;
                    d1_next = mout;
                end
            s2:
                begin
                    in1 = a;
                    in2 = c;
                    d2_next = mout;
                end
        endcase
    end
    
    always @(posedge clk) begin
        d0 <= d0_next;
        d1 <= d1_next;
        d2 <= d2_next;
    end
    


That makes the hardware design clearer, so it’s unambiguous that there’s only one adder. Is this second approach better than the first, then? Mabye, maybe not. If you’re optimizing for space, and don’t trust the synthesis software to be as smart as you are, then the second example is probably better. But if you’re optimizing for speed, having three separate adders (or at least the possibility of three) may actually be better.

Even this second design is somewhat ambiguous. Presumably there are some muxes at the input to the adder, and a mux or load enable at the input to each D register too. But the Verilog code leaves this all implied and unspecified. Here’s a third example that spells everything out in full detail:


    wire [1:0] in1Select, in2Select;
    assign in1 = (in1Select == 2'b00) ? a :
        (in1Select == 2'b01) ? b :
        (in1Select == 2'b10) ? c :
        d;
    assign in2 = (in2Select == 2'b00) ? a :
        (in2Select == 2'b01) ? b :
        (in2Select == 2'b10) ? c :
        d;
    
    assign mout = in1 + in2;
    
    wire loadEnableD0;
    wire loadEnableD1;
    wire loadEnableD2;
    
    always @* begin
        // default: disable all loads
        loadEnableD0 = 1'b0;
        loadEnableD1 = 1'b0;
        loadEnableD2 = 1'b0;
    
        case (state)
            s0:
                begin
                    in1Select = 2'b00;
                    in2Select = 2'b01;
                    loadEnableD0 = 1'b1;
                end
            s1:
                begin
                    in1Select = 2'b01;
                    in2Select = 2'b10;
                    loadEnableD1 = 1'b1;
                end
            s2:
                begin
                    in1Select = 2'b00;
                    in2Select = 2'b10;
                    loadEnableD1 = 1'b1;
                end
        endcase
    end
    
    always @(posedge clk) begin
        if (loadEnableD0)
            d0 <= mout;
        if (loadEnableD1)
            d1 <= mout;
        if (loadEnableD2)
            d2 <= mout;
    end
    


This approach makes it very clear what’s happening in terms of the hardware, and you could build an equivalent physical circuit from 7400 parts. Is this better or worse than the other two approaches? I find it better in terms of understanding what will be synthesized, but it’s worse in terms of length. I also suspect that by specifying all the details in this way, it may be over-constraining the synthesis software, preventing it from using some clever optimizations to pack the same amount of logic into less space.

I find myself going around in circles with variations of these three approaches, unable to really get started with the actual CPU design work.

Working with the Altera software has been pretty good so far, and I’ve been much less frustrated than when I was working with the Xilinx software to create 3DGT from an FPGA. I’m not sure if that’s the software itself, or simply that I’m working on a simpler project and a simpler device, but it’s a welcome change.

I found a couple of similar CPU projects that might provide some inspiration:

MCPU - http://www.opencores.com/project,mcpu - A very tiny CPU that fits in a 32 macrocell CPLD. It has a single 8-bit register, and just a 6-bit (64 word) address space. It also has only four instructions: NOR, ADD, store, and conditional jump. Yet with combinations of those instructions, you can do some pretty complicated stuff. Very clever! Check it out.

MPROZ - http://www.unibwm.de/ikomi/pub/mproz/mproz_e.pdf - MCPU borrows its instruction set from here. MPROZ has a 15-bit address space, but NO data registers. All computation is done directly on locations in memory. It also does MCPU one better by having only three instructions: NOR, ADD, and branch. It fits in an FPGA with 484 macrocells.

I’m attracted to CPLD’s because I’m hoping they’ll provide a good step up from PAL’s, without drowning me in FPGA complexity, as happened when I worked on 3D Graphics Thingy.  I’m pretty confident I can figure out how to work with CPLD’s without driving myself crazy, increasing the chances that I might actually finish this project. Given the limited hardware resources of CPLD’s, fitting a CPU will also be an interesting challenge.

I’ve also been wanting to design my own custom PCB’s for quite some time, and this will give me an opportunity. The end goal of this project will be a single-board computer on a custom PCB, with my CPLD-CPU, RAM, ROM, some input buttons/switches, and some output LEDs/LCD. I need to limit myself to CPLD’s that come in a PLCC package, so I can use a through hole socket and solder it myself. Unfortunately that will limit my choices pretty severely. I think it’s theoretically possible to hand-solder the more common TQFP surface-mount package, but I’m not excited to try it. And for other package types, forget it.

Here’s some back-of-the envelope figuring to get the ball rolling. This is assuming an 8-bit CPU with a 10-bit address space (1K).

I/O pins needed:

• 8 data bus
• 10 address bus
• 1 clock
• 1 /reset
• 1 /irq
• 1 read-write
• ~4 chip selects for RAM, ROM, peripherals

That’s 26 I/Os. So a PLCC-44 package should be fine, as CPLDs in that package typically have about 34 I/Os.

Macrocells needed for holding CPU state:

• 10 program counter
• 10 stack pointer
• 10 scratch/address register
• 8 opcode register
• 3 opcode phase
• 8 accumulator
• 8 index register
• 3 ALU condition codes

That’s 60.

Then I’ll need some macrocells for combinatorial logic. This is a lot harder to predict, and in many cases I should be able to use the combinatorial logic resources and the flip-flop from a single macrocell. I’ll just pull some numbers out of thin air.

Macrocells needed for combinatorial logic:

• 16? arithmetic/logic unit (8-bit add, AND, OR, shift, etc)
• 16? control/sequencing logic
• ??? other stuff I forgot

So that’s a grand-total of 92 macrocells for everything.

If I shrunk the address space down, and maybe changed to a 4-bit word size, I might be able to fit it in a 64 macrocell CPLD. But more than likely, it seems I’ll be looking for a CPLD in the 100 to 128 macrocell range. Considering my requirement for PLCC packaging, that will limit the choices to two or three possibilities, but more on that later.

I think the most challenging part of this project will be the control/sequencing logic, and the assignment of opcodes. BMOW was microcoded, and used a separate microcode ROM to execute a 16-instruction microprogram to implement each CPU instruction. In this case, I’ll need to create dedicated combinatorial logic to drive all the enables, selects, and other inputs in the right sequence to ferry data around the CPU to execute the instructions. Doing this with minimal logic will be a real challenge, and undoubtedly I’ll be using the bits of the opcode itself to derive many of those control signals.

Once I switched to using the CD4013 flip-flop with a positive logic clear input instead of negative logic, it was a piece of cake. I have to say, living just a mile from one of the USA’s largest electronics dealers (Jameco) is pretty sweet. I can hit their web site and place an order for practically any obscure electronic component I can think of, then cruise down to their offices and pick it up from the will-call desk an hour later. Nice!

I rebuilt the decoder circuit that I discussed last time, soldering everything together “dead bug” style. This was necessary in order to keep everything as small as possible, so I could fit it inside the camera body.  I forgot to take a photo before I closed everything up, but it looks very similar to this example from laureanno.com:

When I first connected the servo, decoder, and camera, it didn’t work. Nothing happened when I toggled the switch on my RC transmitter. Setting up the oscilloscope again, I was able to see that the reference pulse width generated by the RC circuit I’d built was about twice as long as it should have been. I’m not sure how that happened, even with 20% tolerance components, but I was able to quickly swap in a different value resistor, and get it working perfectly. Then with a bit of creative packing, I managed to cram it all back inside the camera body.

Today during my lunch hour, I was able to try it out for the first time. The shutter trigger worked fabulously! I wish I could say the same for the quality of the pictures, but unfortunately the focus wasn’t set quite right, and the photos are a little blurry. They’re still pretty fun to look at though. I was flying next to the headquarters of Oracle Corporation in Redwood City, California. Those are the clustered cylinder-shaped mirrored buildings you see in the photos. The plane looks like it was a little higher than the tallest building, which I think is 20 stories tall. See if you can find me in some of the photos!

Click any of the thumbnails below to see the full-sized version.

February 27 Edit: I corrected the focus problem, and tried again. Unfortunately I got the propeller in some of the shots, and this new set wasn’t from as high an altitude. But I did get some great shots of the bay, an aerial self-portrait, and a flock of Canada geese.

I recently bought an Aiptek SD 1.3 megapixel camera, with the idea to mount it on the fuselage of one of my planes, and do some aerial photography. The Aiptek weighs just 52 grams (about 2 ounces), and so it won’t weigh down the plane excessively. But the tricky part is finding a way to activate the shutter while the plane is in the air. It turns out that this is mostly a solved problem, and it’s possible to build a circuit to decode the servo signal from an unused receiver channel, creating a 0 or 1 pulse depending on the position of a transmitter switch or stick. Then by hacking into the camera guts and a bit of soldering, that pulse can be used to trigger the shutter.

Here’s one of my planes (a GWS Slow Stick), with three spare wires hooked into the receiver’s “gear” channel (which I don’t normally use), connected to the oscilloscope and a growing circuit on the protoboard. It turns out that these servo signals for the channels are ideal for hacking with digital logic. Of the three wires connected to the receiver, one is ground, one is a regulated +5 volts, and one is a modulated position signal that indicates the desired position for that channel (rudder, elevator, aileron, flaps, gear, whatever). The connectors are even standard 0.1 inch male headers. What could be easier?

I examined the servo signal with the oscilloscope. It’s a regular pulse train with a 22ms period. The width of the pulse varies depending on the desired position for the channel. The width is about 1.2ms at the minimum position, and 2ms at the maximum position. Taking 1.6ms as the midpoint, what’s needed is a circuit that outputs 0 if the pulse width is less than 1.6ms, and 1 if it’s greater than 1.6ms. This could be done many different ways: the first two that come to mind are a small microcontroller, or a low-pass filter that turns the servo signal into a DC voltage, and compares it to a reference voltage.

I’ve decided to follow another example I found, which I thought was especially clever. It uses just two flip-flops and a couple of passive components. You can check out the circuit schematic for the details. The servo signal pulse train is used to clock the first flip-flop. It’s D input is tied high. When it’s clocked, its Q output goes high, which begins to charge an RC circuit. When the capacitor voltage gets high enough, it activates the asynchronous reset, clearing the Q output. The complementary /Q output is used to clock the second flip-flop, whose D input is the servo signal. If the RC time constant is chosen correctly, then the second flip-flop will be clocked 1.6ms after the first one, sampling the servo signal at that time. If the pulse width is less than 1.6ms it will sample a 0, otherwise it will sample a 1. Pretty neat!

My only headache is that I don’t have the 4013 CMOS flip-flop called for in the circuit. I do have lots of 74LS74 flip-flops, which are similar, but are TTL designs with an active low asynchronous reset instead of active high. I’d thought it would be simple to modify the circuit to work with an active low reset, but after a couple of hours of futzing around with it, I concluded that it’s either not possible, or I’m just not smart enough. I started by swapping the positions of the resistor and capacitor, but the circuit initializes in the reset state and never exits it. And even if I found a solution to that, the input current on this LS series chip is so high, that with a 10K resistor to ground, the voltage at the input pin is actually pulled up to 2 volts! Ack! I decided I’ll just buy a 4013 for a few cents, and stop banging my head.

So what happened? I ran hard into the memory interface wall. Getting a decent DRAM controller working proved to be far, far more difficult than I’d expected, even with the assistance of Xilinx wizards and prebuilt controller packages. And since getting a working memory interface is a precondition to actually doing any of the 3D stuff, well, that sure put a damper on things.

A second reason for failure is that I found working with FPGAs to be abstract and unsatisfying, and the tool software to be a nightmare. When I built BMOW, I was constantly wiring things, debugging with the oscilloscope, buying new chips, soldering switches, and generally being hands-on. In contrast, 3DGT development ended up being nothing but writing Verilog in a text editor, and wondering why the Xilinx synthesis tools never did what I expected them to. The FPGA hardware itself just sat, untouched.

So what’s next? Since last summer, I haven’t done any electronics work at all, except building a light saber from a string of Christmas lights and a flourescent tube cover.  I’ve gotten pretty involved in remote control vehicles, primarily RC planes, which give a few excuses to solder and build simple circuits. I have half an idea to use an Arduino with my Slow Stick somehow, to collect acceleration data in flight, or automate aerial photography or something.

Maybe I’ll come back to the CPU design thing again at some point. I still have a 68008 and some other parts I bought last year that I never got to use, so those are still waiting for me. For all those who contacted me asking if they could build something like BMOW or 3DGT, or asking for advice, send me a note and let me know how your projects are progressing now.

Happy hacking wishes to you all!

No, what seems to be difficult is that the margin for error with DDR2 SDRAM is much smaller than with SRAM or plain (single data rate) SDRAM. The voltages are lower, the timing tolerances are tighter, and much more care must be given to compensating for things like possible skew, processes variation between different FPGAs, power supply tolerances, and a host of other worries.

I’ve been reading a LOT on this topic in the past couple of weeks, and I’ve been struck by one thing. Except for my Xilinx Spartan 3A starter board, and Altera’s comperable Cyclone III board, I’ve seen zero boards that use DDR or DDR2 memory. The all use plain SDR SDRAM, also known as PC100 or PC133 depending on the speed. I looked at boards in the $150 to $300 range from Opal Kelly, KNJN, XESS, and others, and they all use plain SDR SDRAM. Maybe I should take a hint?

Meanwhile, I’ve been digesting as much FPGA documentation as I can. So far I’ve chewed through about 1500 pages of the Xilinx MIG user manual, Spartan 3 series user manual, and Spartan 3A addendum, and I’m midway through the comprehensive book FPGA Prototyping by Verilog Examples: Xilinx Spartan-3 Version. It’s the best “getting started” reference I’ve seen yet, with good coverage of Verilog, FPGA hardware, and the Xilinx software tools.

I still can’t believe all the steps I went through, and the whole process has made me quite bitter about Xilinx’s software tools. I’m sure it would be easier if I had better general knowledge of this field, but the last few weeks of this project have been like being lost at sea, and totally disoriented. It still feels more like a series of disconnected guesses than a genuine understanding, but here’s what I’ve managed to piece together on the topic of using the DDR2 SDRAM that’s on the Spartan 3A kit board.

1. The Xilinx MIG can’t be used to generate a new memory controller design for the Spartan 3A board. This is because the way the SDRAM on the board is connected to the FPGA pins violates some of the MIG design rules. The only solution is to use the pre-built Spartan 3A board reference controller design, which then locks you into a specific burst length and CAS latency, or to hand-modify the code generated by the MIG, which is way beyond the skills of a noob like me.
2. Using the newest version of the Xilinx ISE and MIG, attempting to add the Spartan 3A reference design to your project will cause a crash. No answer from Xilinx support on this.
3. You can also get the Spartan 3A reference design as a zip file. But if you unzip it, add all the files to a new ISE project, and try to build it, you’ll get lots of errors about non-existant nets that I couldn’t resolve.
4. There’s also a batch file in the zip file that will create a new ISE project for you. But try to build it, and you’ll be told that the design requires a ChipScopePro license, which is Xilinx’s software logic analyzer. I found a discussion of this on the Xilinx forums, but no resolution other than to create a new controller design that omits ChipScopePro support, which is impossible for this board due to issue number 1 above.
5. What finally worked was to hand-edit the reference design, deleting parts of it semi-randomly until the ChipScopePro error disappeared. It turned out that required removing three modules called icon, ila, and vio, none of which seemed obviously related to debugging to me.

So there you have it. The next step will be to begin to actually use this interface for something more interesting than lighting up an LED. I’m just now realizing that the interface created by the MIG is just the first, small step towards what the 3DGT memory controller must eventually become. It’s not enough to simply have an interface that permits reading and writing. To achieve half-way decent performance, much care will be required to manage and coordinate those reads and writes, minimizing waiting and wasted time, and maximizing throughput. And to top it off, it’s going to need a bus master to arbitrate memory access between the display circuit, pixel processors, vertex processors, and any other consumers of memory. All this is a substantial project in itself, that will need to be at least partially completed before any real progress can begin on the 3D part of 3DGT. Looks like a long, slow climb, but I’m moving ahead.

1. Create new project
2. Run “memory interface generator” wizard (which Xilinx calls the M.I.G.)
3. Choose memory type, speed, etc.
4. The wizard adds some auto-generated .v and .ucf (user constraints) files to my project
5. Optionally, wizard also adds a test bench, or some kind of example
6. Synthesize the example, program it to the starter kit, and blink some LEDs to show that it worked.

That was the theory anyway. The reality has been a long series of software errors and omissions too dull to recount in detail. The short version is that when I use the MIG to generate an interface specifically for the Spartan 3A starter kit, the MIG crashes. If I follow some hazy instructions for manually adding the reference design to the project without using the MIG, then I get something that fails the “translate” step. If I use the MIG to generate a new interface design for a board that just happens to have the same hardware as the Spartan 3A starter kit, I also get something that fails the “translate” step. In either case, before the fatal errors, there are many warnings saying that dozens of flip-flops were determined to have a constant 0 or 1 value, and so were optimized away, as well as copious other warnings. Clearly I’m doing something very wrong, but creating a sample design using the reference memory interface on the reference board seems like it should be about as simple a case as it’s possible to get.

I would have given up on it a while ago, except that with no memory interface, there can be no 3D Graphics Thingy. This simply must be made to work in order for the project to progress any further. Unfortunately I’m about out of ideas. I need to find a simple walk-through tutorial that starts with “open ISE, press the New Project button” and finishes with happy green checkmarks next to all the steps in the processes window for an example design using the MIG controller. There are only about 10 mouse clicks needed between that start and finish, so it would seem hard to mess it up much. Either I’m doing something basic wrong, or omitting something, or my computer is haunted. With luck, it will become clear tomorrow.

I wrote earlier about some basic bandwidth estimates, and have revised them somewhat here. Assume pixels and texels are 16 bits (5-6-5 RGB format), z-buffer entries are 24 bits, and the screen resolution is 640×480 @ 60Hz. Let’s also assume a simple case where there’s no alpha blending being performed, and every triangle has one texture applied to it, using point sampling for the texture lookup. For every pixel, every frame, the hardware must:

1. Clear the z-buffer, at the start of the frame: 3 bytes
2. Clear the frame buffer, at the start of the frame: 2 bytes
3. Read the z-buffer, when a new pixel is being drawn: 3 bytes
4. Write the z-buffer, if the Z test passes: 3 bytes
5. Read the texture data, if the Z test passes: 2 bytes
6. Write the frame buffer, if the Z test passes: 2 bytes
7. Read the frame buffer, when the display circuit paints the screen: 2 bytes

Assume too that the scene’s depth complexity is 4, meaning the average pixel is covered by 4 triangles, and steps 3-6 will be repeated 4 times. Add everything up, and that’s 47 bytes per pixel, times 640 x 480 is 14.43 MB per frame, times 60 Hz is 866.3 MB/s.

The DDR2 memory on the Xilinx starter kit board has a theoretical maximum bandwidth of 1064 MB/s, so that might just fit. I have serious reservations about my ability to later recreate such a high-speed memory interface on a custom PCB, but ignore that for now. Unfortunately you’ll never get anything close to the theoretical bandwidth in real world usage, unless you’re streaming a huge chunk of data to consecutive memory addreses. Even half the theoretical bandwidth would be doing well. I’ll be conservative and assume I can reach 1/3 of the theoretical bandwidth, which means 355 MB/s. That’s not enough. And I’ll also need some bandwidth for vertex manipulations, since I’ve only considered pixel rasterization, and possibly for CPU operations too. It looks like things will definitely be bandwidth constrained.

Fortunately there are some clever tricks that can be used to save lots of memory bandwidth.

1. Z occlusion: When a pixel fails the Z test at step 3, then steps 4-6 can be skipped. With a depth complexity of 4, and assuming randomly-ordered triangles, then on average 1 + 1/2 + 1/3 + 1/4 = 2.08 triangles will pass the Z test and get drawn, not 4. That’s a savings of 14 bytes per pixel, or 258 MB/s!
2. Back-face culling: When drawing solid objects, it’s guaranteed that any triangle facing away from the camera will be overdrawn by some other triangle facing towards the camera. These back-face triangles can be ignored completely, skipping steps 3-6 and saving 10 bytes per culled pixel. Assuming half the pixels are part of back-facing triangles, then that’s a savings of 369 MB/s. Of course some of the pixels rejected due to back-face culling would also have been rejected by Z occlusion, so it’s not valid to simply add the savings from the two techniques.
3. Z pre-pass: Another technique is to draw the entire scene while skipping steps 5 and 6, so only the Z buffer is updated. Then the scene is drawn again, but step 3 is changed to test for an exactly equal Z value, and step 4 is eliminated. This guarantees that steps 5 and 6 are only performed once per pixel, for the front-most triangle. However, step 3 must now be performed twice as many times, and all the vertex transformation and triangle setup work not accounted for here must be done twice. Whether this results in an appreciable overall savings depends on many factors.
4. Skip frame buffer clear: If the rendered scene is indoors and covers the entire screen, then the frame buffer clear in step 2 can be omitted. That’s a savings of 37 MB/s.
5. Skip Z-buffer clear: If the rendered scene covers the entire screen, then the Z-buffer clear in step 1 can also be omitted, but sacrificing one bit of Z-buffer accuracy. On even frames, the low half of the Z-buffer range can be used. On odd frames, the high half can be used, along with a reversal in the sense of direction, so larger values are treated as being closer to the camera. This means that every Z value from an even frame is farther away than any Z value from an odd frame, so each frame effectively clears the Z-buffer for the next one. This provides a savings of 55 MB/s.
6. Texture compression: Compression formats like DXT1 can provide a 4:1 or better compression ratio for texture data. If the rasterizer can be structured so that an entire texture is read into a cache, and then used for calculations on many adjacent pixels, this can translate directly into a 4:1 bandwidth savings on step 5. Assuming less than perfect gains of 2:1, that translates to a savings of 18 MB/s.
7. Texture cache: Neighboring pixels on the screen are likely to access the same texels, when the textures are drawn magnified. A texture that’s tiled many times across the face of a triangle may also result in many reads of the same texel. The expected savings depend on the particular model that’s rendered, but are probably similar to those for texture compression, or about 18 MB/s.
8. Tiled Z-Buffer: The Z-buffer can be divided into many 8×8 squares, with a small amount of state data cached for each square: the farthest point (largest Z value) in the square, and a flag indicating if the square has been cleared. That’s 25 bits per square, or 15 KB for a 640×480 Z-buffer. That should fit in the FPGA’s block RAM. Then when considering a pixel before step 3, if the pixel’s Z value is larger than the cached Z-max for that square, the pixel can be rejected without actually doing the Z-buffer read. Furthermore, when the Z-buffer needs to be cleared, the cleared flag for the block can be set without actually clearing the Z-buffer values. Then the next time that Z-buffer square is read, if the cleared flag is set, the hardware can return a square filled with Z-far without actually reading the Z-buffer values. This skips both a Z write and a Z read for the entire square. In order to gain the benefit of the cleared flag, the hardware must operate on entire 8×8 blocks at once before writing the result back to the Z-buffer. The total savings for both these techniques is at least 110 MB/s, and possibly as much as 165 MB/s depending on how much is occluded with the square-level Z test.
9. Z-buffer compression: 8×8 blocks of Z-buffer data can be stored compressed in memory, using some kind of differential encoding scheme. Like the previous technique, this would require the hardware to operate on an entire 8×8 block at a time in order to see any benefit. The cost of all Z-buffer reads and writes might be reduced by 2:1 to 4:1, at the cost of additional latency and hardware complexity to handle the compression. This could provide a savings in the range of 350 MB/s.

Unfortunately the savings from all these techniques can’t merely be summed, and the savings I’ve estimated for each one are assuming it’s done by itself, without any of the other techniques. However, when used together, the combination of backface culling plus Z-occlusion should provide at least 400 MB/s in savings, texture compression and caching another 30 MB/s, and Z-buffer tiling another 110 MB/s. That lowers the total bandwidth needs down to 326 MB/s, roughly the same as my conservative estimate of real-world available bandwidth.