So, what the heck, I'll look at timing before slapping something together. Here's a simplified schematic of the guts of the VGA framebuffer (it ignores the reset and connections between the two '4040's required to generate 19 bits of address). The dot clock is 25.175 MHz, for a period of about 39.7 ns.

Looks simple, right? I started with 74HC logic - the 74HC4040 has a typical count frequency of 90 MHz, which sounds plenty fast. In the schematic above, the '4040 counters increment the address on the rising edge of the clock, while the '574 d-flop captures the data from the last address before it changes. I'm going to ignore those timing calculations for the moment (next log) because there's an even bigger problem here - it takes too long for the address to settle. The AS7C4096A-12 SRAM has a 12 ns access time, so the addess has to be stable within about 39-12 = 27 ns to work (ignoring setup time for the output register).

In the 74HC4040 datasheet, it specifies a tpd from CP to Q0 of 14 ns (typ at 5V). I'm using typical values for the moment; if it doesn't work there, it's not going to work worst-case, either. It further specifies the tpd from Qn to Qn+1 as 8 ns. Since it's a ripple counter, Q0 flips, then Q1, then Q2, etc, so we have to add all the delays so see how long it takes for the address to settle to the next value. When all of the bits have to change state, it takes 14 + 11 * 8 = 102 ns for the output lines to show the correct address - that's way too long, since we have less than 40ns to get the next byte of data out. This also ignores the fact that two 74HC4040s need to be chained to generate the 19-bit address: in that case, we're looking at 14 + 11*8 + 14 + 6*8 = 164 ns for all the address bits to settle.

VHC to the rescue?

I haven't used VHC logic before, but keep seeing it around. Surely the 74VHC4040, with its 210 Mhz typical max clock frequency will do the job! Let's run the numbers, using a 15pF load : tpd (CP to Q0) = 4.8 ns, and tpd (Qn to Qn+1) = 1.6ns. So, with two of them connected to generate 19 bits of address, the tpd from the clock edge to the MSB settling is: 4.8 + 11*1.6 + 4.8 + 6*1.6 = 36.8 ns. Add in the 12 ns access time of the SRAM, and we're definitely over budget.

It's a shame, because the '4040 packs 12-bits into a single package. I have to go take them out of my shopping cart now :-)

What about the '393 counters?

The 74VHC393 is another candidate - it has twin 4-bit counters in a package, so three ICs would be necessary. I started with the VHC part this time :-) In this case, the propagation delays are specified for each of the four bits. For Qd (the fourth bit), the typical tpd is given as 8.5ns (assuming a 15pF load), and the Qc tpd is 7.7 ns (the third bit). With five counters chained, the typical time to get the 19th bit settled is 4*8.5 + 7.7 = 41.7 ns. Nope.

Synchronous Counters

Synchronous counters use extra logic to form the next state from the previous one directly, without waiting for clocks to ripple through, so the outputs settle faster. The disadvantage is that they seem to only be available in 4-bits/package. Now, I need 5 ICs to make the counter - if it's even fast enough. The 74VHC163 claims 185 MHz at 5V - maybe that will work. Interestingly, it also has a synchronous clear, and connections for synchronous expansion between counters with lookahead carry outputs. If I'm reading the datasheet correctly, the maximum delay from clock edge to valid outputs is 10.1 ns (at 5V) - even expanded to 20 bits. This would work - with the 12ns SRAM access time, still way under the 40ns cycle time.

How about the 74HC163? 74HC parts aren't specified at 5V for some strange reason, but at 6V, the tpd (max) is 35 ns, and at 4.5V it's 41 ns. Doesn't look promising - although the typical 21ns (6V) or 25ns (4.5V) sound workable.

If I were going to build a bunch of these, I'd try harder to get the 74HC163 to work. Since I'm only building one, and on a deadline, I'll spring for the more expensive 74VHC163s. I need 5 of them, which sucks.

The clock input on the '163 works on the positive edge, so the schematic above changes a bit, but at least the addresses seem OK. Next step - the rest of the logic and timing calculations.

Did I miss something on the ripple counters? Maybe I'm doing this wrong?

This is where a little CPLD would be nice - but that would count against my 1kB ;-)

PIC Address Generation?

What about using the fastest PIC available and bitbanging the address lines? The fastest ones I can find are 64MHz, or 16 MIPS. Even if you could output a new address every cycle, that's still only about half of the 25.175 MHz clock required. Maybe a fast external counter for the lowest 4 (or 8) bits, and the PIC generates the upper ones? Synchronization is an issue, but it's worth thinking about - maybe if the PIC runs from the external 25.175 MHz clock, and synchronizes itself with the external low-bit counter(s)? This could be interesting.