Hacker News Reader

Comment by jacquesm | Hacker News Reader

This was quite common. You only decode out as much as you need and if that results in phantom appearances of devices or ROM as long as it doesn't interfere with the operation of the device that is perfectly ok. Memory map aesthetics are important but sometimes circuit simplicity is more important.

View on HN

I think it's still 'buggy' if the result is a bus fight (that might actually damage chips)

It shouldn't, normally unless you designed the map wrong. That would be a real fault. In some systems it was possible to use dynamic map changes to position ROM over RAM and then to do weird things like getting the CPU to write to ROM but I've never heard of that actually damaging anything though speculation that in a tight loop that should be possible was rampant. We sure tried ;)

But when decoding banks of addresses you'd typically decode just one chip at the time, but possibly in multiple locations, otherwise vacant.

They are probably using A[19] as chip select for one device, A[18] for a different one, etc.

So if you read from 0x000c0000, you get a conflict.

I wouldn't call it a bug if it's done deliberately to save some gates. :-)

Heh, clever. But you'd be even smarter to hook A19 to ~CS and A18 to ~EN to get the same effect without the conflict.

That would require two additional NOT gates, which, in turn, would require an additional chip, which given the layout of the board, would require additional board space.

But what would the benefit be, other than a somewhat cleaner address space? You don't get to actually use the space that isn't mapped in this scenario--RAM, or whatever, doesn't magically appear there. You also end up having to worry about additional gate delay.

So, from the software's perspective, you go from, "Don't use these addresses, unpredictable things will happen." to "Don't use these addresses, nothing will happen."

Either way, code that uses these addresses is buggy. So you are paying extra hardware for very minimal benefit.

> So, from the software's perspective, you go from, "Don't use these addresses, unpredictable things will happen." to "Don't use these addresses, nothing will happen."

If the address decoder allows certain address ranges to select more than one device (which appears to be the case), the problem is far more serious: don't use those addresses [even for reads!] because it will literally fry the output drivers of the conflicting chips.

Bus conflict damage is largely a myth, at least for modern ICs. Output drivers are a lot more robust than you think. More likely the extra current will cause a reset or glitch if the power supply circuitry/decoupling can't keep up with the current spike.

Really? So a CMOS driver that's driving a high logic level which is connected to a CMOS driver that's driving a low logic level won't get destroyed by the resultant short circuit?

As far as I understand (and I admit that I might be wrong here) a typical CMOS driver outputs a high logic level by connecting the output pin to Vcc (via a low-resistance FET) and it outputs a low logic level by connecting the output pin to GND (also via a low-resistance FET). And the circuit traces on the bus are also fairly low resistance. Wouldn't this short circuit result in dangerously high currents flowing?

Certainly high enough (>100mA) to violate the device's "absolute maximum ratings", the ones that you aren't supposed to exceed even momentarily?

I'd be very interested to hear more about the robustness of output drivers and the amount of abuse they can tolerate.

You're correct about how the outputs work, but the practical reality is that currents end up limited enough by the FET's on resistance that nothing gets damaged. Yes, it's outside the spec, but exceeding the AMRs doesn't mean your chip dies. I had a 5V microcontroller survive being put across 12V once. And I had a Threadripper motherboard die by shorting out its CPU Vcore FET, which would send the PSU's 12V rail into the CPU, and the CPU survived (PSU shut down before any damage was done).

If shorting a pin to the opposite rail destroyed your IC people would be destroying Arduinos left and right with trivial mistakes while experimenting, and they wouldn't be able to get away with having no I/O protection :-). You usually don't get >100mA out of a single IO line short - maybe 50mA. Having a bunch of paralleled bus contention can cause more damage (not to the drivers, but to power routing and other shared resources), but at that point you should be hitting PSU current protection limits (which are more important for overall design robustness).

Console modchips of olde (PS1/2/GameCube/etc) worked by overdriving bus lines with a stronger driver (often multiple lines ganged together). No consoles were hurt by this.

I did part of the design and board layout for Glasgow revC, an FPGA-based USB interface board, and I stress tested our IO level shifter chips for short circuit robustness. Leaving the outputs shorted hard to the opposite rail overnight did no apparent harm (bypassing the protection resistors), other than getting the chip nice and toasty for the duration of the test.

Edit: just remembered a personal anecdote. I only recall ever killing an output driver with a short, on a typical microcontroller, once in my life (could've been a fluke). And I've done many stupid experiments. Shorting outputs briefly for experimentation or unorthodox workarounds is solidly in the "no big deal" category in my mind, and it's practically never been a problem. E.g. "I don't know which side is TX and RX in this UART, so I'll just try both" "This device is bricked so let me short out the flash to force it to fall back to bootloader mode", etc.

> I stress tested our IO level shifter chips for short circuit robustness. Leaving the outputs shorted hard to the opposite rail overnight did no apparent harm (bypassing the protection resistors), other than getting the chip nice and toasty for the duration of the test.

That's impressive!

Thanks for the reply, sounds like I can be a bit less cautious without fear of blowing things up.

I've never seen this happen on the time-scales that a CPU runs at. Such short time shorts would cause a local voltage drop but nothing you could not handle with a small cap.

Have you actually ever fried a chip because of a bus conflict?

yes - not a short term one though, some thing got too hot for too long - it really depends on how the gates are built, the width of the bonding wires etc etc

No, you would not need NOT gates, you'd just have the chip appear at the different spot. They're address lines, after all.

That's fair; I hesitated to call it buggy, because a well-understood bug that's documented and easy to work around or ignore and which nets you some benefit is only barely a bug at all.

I'd classify it under "hack that is fine if you know what you're doing". Fancier 68K systems would use a PAL for address decoding, primitive programmable logic.

PALs are expensive and required programming '138s and '154s were cheap and work out of the box.

I used to feel that way, until I replaced about ten 7400 series in my address decoder with one 16v8 that costs around a dollar and frees me from propagation delay concerns... YMMV of course :)

Yes but how long is Microchip going to continue producing the 16V8? They're the only remaining manufacturer. At least with 74xx138 decoders you have several suppliers available -- not to mention the choice of multiple logic families to select from.

If you're willing to accept address aliasing (i.e. chips appearing at more than one memory address) you can simply use multiple '138 decoders in parallel to make a 1-of-24 or 1-of-32 decoder. In fact that's precisely why the '138 has so many enable inputs: the one active high (G1) and two active low (~G2A and ~G2B)enable inputs let you build a 1-of-24 decoder using three '138 chips and zero additional glue.

Fair point, but I happen to have a few thousand ATF16V8BQLs in stock, so I'm not worried for the time being :) Originally (on breadboard) the project didn't use any programmable logic, but board space dictated that I switch to them when I did the first PCB.

That's the difference between doing it professionally and doing it on a hobby budget.

Doesn't matter too much for hobby projects though, even if they go EOL there's still plenty on eBay.

Partial decoding, causing aliases, is indeed common and mostly not a problem. What this system appears to have is overlapping decoding. I can't say I've seen any system until now that was deliberately designed that way.

Reply on news.ycombinator.com