1
\$\begingroup\$

Electronics newbie here...

I'm trying to build a retrocomputer, and learn digital electronics along the way. I decided to begin with the video generation part, with a fast memory copier, independent of the main processor. I don't really want to use an FPGA, I'm trying to do it the "old" way, like this guy did.

I would like to create a breadboard circuit that copies addresses "SA".."SB" of SRAM chip 1 to addresses "DA"+ of SRAM chip 2, as fast as possible. A sort of hardware fast memcopy machine.

The SRAM chips are 12ns 32Kx8 Renesas IDT71256SA (datasheet).

SA and DA would be stored inside synchronous 4bit binary counters (4 SN74F163AN‎ chips each, datasheet), SB would reside in a buffer (SN74F541N), and I would use an identity comparator (2 SN74F521N) between SA and SB to eventually stop the counters, and thus the copy operation.

The counters would be connected like this (I understand this is the fastest way to cascade them):

16bit synchronous counter

I would like to use a 32 MHz clock (I know, that's a lot for a breadboard, but I hope to handle it by using uniform short wire lengths and some .01uF decoupling capacitors on the power rails and the SRAM's Vcc and GND pins), but I don't know if that's too fast for the chips.

During the copy operation, pin CS and OE of chip 1 would be low, as well as pin WE of chip 2. I would control chip 2 writing with the CS pin.

I'm having trouble understanding the timings in the datasheets. Can anybody help me figuring out:

  1. The maximum update delay of the 4 cascading counters i.e. how many ns does each counter add to the total.
  2. How many ns pass (at most) from the clock transition low to high and a stable data (valid) coming out of chip 1.
  3. If the above is less than 30ns (the clock cycle), maybe I could latch it in a fast latch so that chip 2 can use it as its data-in. That way while chip 1 reads a byte, chip 2 writes the previous one, effectively copying at 32MB/sec speed.
  4. If that is possible, how do I make chip 2 skip only the first clock cycle?
  5. If that's not possible, what would you change to make it work at such speeds?
\$\endgroup\$
10
  • 1
    \$\begingroup\$ "fastest possible" and "32 MHz" are incompatible for a device that can cycle at 80 MHz. In any case why are you using low performance discretes when 200 to 400 MHz would be easy in a small FPGA? What are you REALLY trying to do? 74F series saved my ass in 1983 but .. maybe ask on retrocomputing.SE? \$\endgroup\$
    – user16324
    May 7, 2020 at 14:28
  • 2
    \$\begingroup\$ "32 MHz clock" and "breadboard": might work, but would not recommend. At 32 MHz, and especially its harmonics, the average breadboard works more like a network of parasitic inductors and capacitors; for slow-speed prototyping, sure, might work, I personally would have not the patience to make sure all connections are reliable enough, but I'm not convinced you'd want to operate it at full frequency :) \$\endgroup\$ May 7, 2020 at 14:28
  • 1
    \$\begingroup\$ @BrianDrummond Effectively, I would like to build a retrocomputer, and learn digial electronics along the way. I decided to begin with the video generation part, with a fast memory copier, independent of the main processor. I don't really want to use an FPGA unless necessary, I'm trying to do it the "1983" way, as you said... \$\endgroup\$ May 7, 2020 at 14:42
  • 1
    \$\begingroup\$ That clarification should be in the question, \$\endgroup\$
    – user16324
    May 7, 2020 at 14:46
  • 1
    \$\begingroup\$ Clocking one IC on a breadboard is not the same as clocking a bunch of parts. What's going to kill you is reflections on the clock signal that are going to cause your devices to mis-count. Piggybacking on what Marcus said, many years ago I had a wire-wrapped board. It ran at 15 MHz OK. At 20 MHz it worked once in a while. At 25 MHz it worked once! \$\endgroup\$
    – SteveSh
    May 7, 2020 at 14:59

2 Answers 2

2
\$\begingroup\$

"I would like to build a retrocomputer,"

So the question isn't about the "fastest possible" solution but about how to get a whole circuit humming along at a reasonable 32MHz or so...

Consider wire-wrap on protoboard instead of breadboard (with soldered power supply and decoupling, and good ground connections or even a ground plane) - easy enough prototyping and a whole lot more reliable - and "in period" so to speak.

To answer your specific questions :

1) No additional time at all, if you are using them correctly (and counting in powers of two) - 163s are synchronous counters, not ripple counters like the 7493.

2) See the datasheet. If you have questions about that, ask for help.

3) Yes, you are starting to build a "pipeline" which allows one stage to work on the new address while another uses the previous. This is how it was done. With a good understanding, you should be able to get away with 25 ns memories instead of 12 ns at these speeds. Draw timing diagrams, from the datasheet values, until it looks as if it should work.

4,5) N/A

\$\endgroup\$
2
\$\begingroup\$

Good work on diving in and learning.

Regarding the timing of the counters, remember that they're registered state machines, so cascading more 74F163 counters does not change the clock-to-output delay, which is 11ns worst case according to the datasheet: 74F163 propagation delay

What changes is the setup time margin for the cascaded counters' enable inputs. Reviewing what you probably already know, setup time is the amount of time that the data at the inputs of a registered state machine must be valid before the clock edge. Here are the setup time specs for the 74F163: 74F163 setup time

At 33 MHz, one clock cycle is 31.25ns, but we need 11.5ns of setup time at the ENP/ENT inputs, so we are down to 19.75ns to compute the ripple carry count enable between stages.

The count enable path timing starts with the clock-to-output delay for the first (lowest-order) RCO output, which is 15ns: 74F163 clock-to-RCO propagation delay

Then there's the asynchronous delay of 8.5ns: 74F163 ENT-to-RCO propagation delay

So, the total worst-case delay is 15ns for the clock-to-RCO delay, 8.5ns for the ENT-to-RCO delay, and then 11.5ns for the ENP/ENT setup time. So that's a minimum worst-case clock period of 35ns for just the counter, not even including the SRAM.

This timing analysis was done against the maximum/worst-case specs at 85 degC. You can do things to get the system to run fast, like heavily cooling the system, running at 5.25V-5.5V, etc. and then design to the typical timing specifications, rather than the worst-case. That makes everything much harder though, as you have to pay much more attention to the actual system timing, rather than the more conservative worst-case data sheet specs. So I would design conservatively to the worst-case specs when possible.

Try implementing the entire 16-bit counter in a CPLD like an Altera MAX7000S, e.g. EPM7128SLC84. This is a large PLCC-84 surface-mount part which you can put in a through-hole socket. You can get EPM7128SLC84 chips on eBay (they're all used socket pulls) for $2-3 each if you are willing to sort through some bad chips and return them. Around half you get will not work for various reasons but the sellers will always refund if you are persistent. Use Altera Quartus II 13.0SP1 Web Edition to program the CPLD. You will also need a "USB Blaster" to connect to the chip, and make sure to get a MAX7000S-series chip, not a MAX7000E or MAX7000 or else the USB blaster will not be able to program it.

As for constructing a system like this, it will be difficult to make it work on a breadboard. Without a ground plane to confine the switching noise near the traces making the noise, each time you add another wire, the crosstalk all over your breadboard will increase.

My favorite way to construct this kind of system is to solder it on a prototyping board. Breadboards are quick and easy for small projects, but with hundreds of wires going around, the time spent soldering is worth it to make sure none of the wires come out of the board accidentally.

The most useful thing about prototyping board in this context, though, is that you can short the majority of the through-holes together with solder to form a rudimentary ground plane. Just make sure to also use wire between the IC ground pins to lower the resistance. You can also use copper tape to make a shield or ground plane.

For your clock signal, try to cluster all of your loads (pins receiving the clock signal) near the end of a wire. Avoid multi-drop clock distribution, where the clock signal meanders around, hitting different chips as it goes around the board. If this isn't possible, try a using clock buffer at the very root of your clock tree to make multiple copies of the clock which you send to different chips. You can also use micro-coax to distribute the clock.

Check out this guy's old project for some inspiration on wire-wrap/prototype board construction (skip to around 8:00 if you're in a hurry to see his hand-wired prototype techniques): https://www.youtube.com/watch?v=C8txvmXUIJQ

\$\endgroup\$
10
  • \$\begingroup\$ Thanks very much for the time you spent looking into this and making things more clear, it's really appreciated. \$\endgroup\$ May 7, 2020 at 18:18
  • \$\begingroup\$ You’re welcome! One more thing—when I was a beginning digital designer, just a few years ago, I wanted to design a system like you’re describing, a fast little microcomputer with video output, made with 74xx logic. I thought that using 74xx parts would give it a certain quaintness and simplicity. Actually though, the granularity of these parts is a bit too fine, and you end up with a complex and brittle system. \$\endgroup\$ May 7, 2020 at 20:56
  • \$\begingroup\$ You wanted a 16-bit counter, for example, but you’ve got to cascade four chips and then it’s not fast enough. Moreover, these 74xx MSI chips often have features that you don’t want, but lack the one that would make it fit into your system better, necessitating additional gates to glue everything together. \$\endgroup\$ May 7, 2020 at 20:57
  • \$\begingroup\$ In later systems, this kind of “glue logic” was used only between LSI parts like processors and DRAM. But if you’re not careful when designing with 74xx logic, you will need glue logic between the blocks of MSI 74xx like between your 4-chip counter and the rest of your system. Only with a comprehensive and specific knowledge of the MSI 74xx parts available can you design a system that doesn’t require much glue logic, and then there are still issues. \$\endgroup\$ May 7, 2020 at 20:57
  • \$\begingroup\$ Wozniak, designer of the Apple II, was a master of fitting 74xx parts together to do a lot with few chips. If you are really interested in doing a lot with 74xx, I suggest you study the Apple II. But you will come to see that, because of Wozniak’s quirky, chip-saving use of 74xx, the Apple II has a number of idiosyncrasies, and it’s also not very fast. \$\endgroup\$ May 7, 2020 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.