Etydhv

I was browsing Microprocessor Interfacing Techniques and found this pharagraph:

The microprocessor's buses must connect to every memory and peripheral input-output chip in a system. All MOS microprocessors lack the output drive needed for a large system. Because of this, buffers or drivers are used to boost the driving power of the buses.

I'm not sure what the definition of a large system is, but from the (simple) microprocessor hobby system designs I've seen the usage of buffers/drivers doesn't seem to be common.

How do I know when I need to use buffers/drivers in my design? My gut feeling based on my rudimentary knowledge is that I probably need it when my signals go off the board and interface with unknown components, e.g. in a S-100 system. Is this something I can calculate?

Large is when the processor cannot drive the various signals properly and that comes down to a number of things but primarily it is the number of devices on the bus.

They all present a load to the drivers and this is not just for the processor - during the read process where the peripheral drives the bus the load is now from the peripheral perspective. There are a couple of issues to deal with here: Fanout and capacitive load. At higher edge rates the loss tangent and skin effect also have to be considered.

Note that in modern all CMOS systems, fanout (from a pure DC current perspective) is not that much of an issue, although a significant current pulse is consumed by a CMOS input when switching but still far less than the old TTL input current.

Using a somewhat mature device that has a parallel bus (which is the main area that this issue comes up) we can look at the drive capability of the outputs:

The outputs that are expected to drive multiple inputs have a higher output current capability and in fact, that is not really an issue with modern controllers unless you are driving long runs such as backplanes (where transmission line losses - see below) come into play; what is an issue is the capacitive load.

Taking a value from the table for an address bit (The first entry) we can drive up to 24 mA and 15pF. The driver could drive more capacitance, but then the timings in the other tables will not be valid; this could easily violate setup and hold timing requirements and would require possibly significant analysis.

If there are 4 devices on the bus (not unusual) and each has a pin capacitance of 4pF (quite common for parallel interfaces) then we have 16pF loading even without considering track capacitance. For reference, a 4 thou (100 micron) track over a plane (or some return path at least) with a 4 thou core is about 1.1pF / inch. It doesn't take much track to exceed the loading specification.

Modern devices do usually come with an IBIS model so that this can be explored at system level but that requires a (usually expensive) simulation tool (typical tool linked). It is possible to analyse such interfaces by hand but it is time consuming and can be somewhat error prone.

Staying within the table limits permits a hand calculation of interface timing, at least for relatively slow edge rates. A slow edge rate is (my rule of thumb) is where the signal propagation delay on the PCB is less than 1/6 of the edge rate itself. If the edge rate is 1nsec (about 6 inches on most flavours of FR-4) then a track length of less than an inch requires little further analysis.

If we have fast edge rates, then we are in transmission line territory and the losses due to skin effect and dielectric absorption need to be considered and may well add buffering requirements.

For completeness, we can take a look at a reasonably modern parallel flash device.

Here is the table for output drive:

As can be seen, this part requires no more than 100uA of output load to meet the necessary timing. The datasheet also specifies a load capacitance of no more than 30pF.

So if you have:

Long tracks, heavy loads or fast signalling you may need to buffer various signals. Note that once you buffer one signal you will usually need to buffer all the signals in the group to maintain group timing.