Technical Q&A HW03

NuBus Timing Problem

Q: We developed a NuBus card using the Texas Instruments chip set (74ACT2440 and 74BBCT2420) that performs DMA-in and DMA-out. With the card installed in a Quadra 840AV, the Macintosh gets stuck in a DMA-out and needs to be rebooted after several DMAs. We used a logic analyzer to try to determine what is going wrong, but we could not find out what is causing this problem, as the bus is idle at the time the problem occurs.

Since the same card works properly, and has for approximately three years, in other Macintosh models (e.g., Quadra 900, Macintosh II, PowerMac 8100, Macintosh IIfx), is there anything different about the NuBus in the Quadra 840AV?

A: Your problem may be caused by a NuBus timing error that was uncovered by the MUNI chip. The MUNI chip was designed to perform much faster than the older NuBus controllers, and therefore is not as tolerant of timing errors.

While the Quadra 800, and Centris 650 have the KIWI NuBUS ASIC in them, the 840AV has the MUNI NuBUS ASIC. Both of these ASICs have much tighter timing margins to support NuBUS 90 and higher-speed burst transfers. The clock duty cycle of these ASICs is tighter (it is now very close to the 75/25 specification), and some developers have reported problems as a result.

Be sure to sample the correct edge of the NuBUS clock, per the NuBUS '90 specification. Even if your product works properly on the KIWI chip, there may be subtle timing and/or electrical changes in the MUNI chip that are causing your problem.

A similar problem was reported on the Macintosh Quadra 900/950 with the YANC chip and very fast transfers. The timing is such that the YANC (Yet Another NuBus Controller) chip, which came before KIWI and MUNI, gets lost on the Quadra. One developer was trying to transfer four longs by holding REQ* asserted and was not using attention cycles. Because YANC lost the last arbitration, it looked for start, but it was one clock cycle too late (after the start cycle). As a result, it got lost, and the system hung. Although this problem doesn't exhibit exactly the same symptoms as the problem you are experiencing, there are enough similarities to indicate that both problems are probably caused by the timing differences.

The solution provided to that developer was to use attention-lock, transfer the four long words, and then do an attention-null to re-sync the YANC. This does add some overhead, but it is better than putting a dead cycle after every ACK*, which would make transfers three cycles long instead of two. This approach might solve your problem, as well.

Here's another possible cause: The Muni chip generates a NuBus timeout error if the entire NuBus transaction takes more than 256 cycles (25.6 µsec) after Start occurs. For Block Transfers, the entire block must complete within 25.6 µsec. Muni generates a timeout error after 25.6 µsec, whether it initiated the NuBus transaction or not (e.g., if the transaction is between two NuBus cards).