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
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. :-)