5 ms·

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

jacquesm 6y ago
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.
- TomVDB 6y ago
  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. :-)
  - jacquesm 6y ago
    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.
    - compiler-guy 6y ago
      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.
      - kiwidrew 6y ago
        > 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.
        marcan_42 6y ago
        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.
        kiwidrew 6y ago
        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.
        marcan_42 6y ago
        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.

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.

TomVDB 6y ago
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. :-)
- jacquesm 6y ago
  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.
  - compiler-guy 6y ago
    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.
    - kiwidrew 6y ago
      > 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.
      - marcan_42 6y ago
        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.
        kiwidrew 6y ago
        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.
        marcan_42 6y ago
        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.