Benutzer:Rdiez/HardwareDesign

Dies sind die persönlichen Benutzerseiten von rdiez, bitte nicht verändern! Ausnahmen sind nur einfache Sprachkorrekturen wie Tippfehler, falsche Präpositionen oder Ähnliches. Alles andere bitte nur dem Benutzer melden!

Hardware Design Ramblings

Reset Behaviour Rules

• If the user wishes to reset the device and holds the Reset button down, all components should immediately reset and remain in the reset state. All signals should go to a defined level.
  You don't want your device to become an uncontrolled source of electromagnetic interference (EMI) during reset, so there should be no wires left in a high impedance state (also known as hi-Z, tri-stated, or floating). Your device should not do weird things like amplify noise during reset (high impedance lines can act like antennas). In practice, this means adding pull-up or pull-down resistors to all lines.
  You cannot assume that the user will hold the Reset button for a very short time. The software may also need to temporarily reset parts of the system (see further below), and having random signal values may occasionaly trigger subtle bugs on reset, which tend to be hard to reproduce. Besides, having a defined reset state may help testers if they need to keep some subsytems under reset for specific test cases.
  This system-wide reset signal should also be routed to the SRST pin on the JTAG debug interface. This way, the device will always behave the same during start-up, no matter where the reset comes from, which will simplify the software and reduce the scope for initialisation bugs.

• When the user releases the Reset button, the main CPU alone should come out of reset.
  Only those components that are truly necessary for the CPU to start should come out of reset at this point in time. All other components should remain in the reset state.
  This rule is normally easy to implement, because most CPUs revert their I/O pins to floating inputs when under reset. If you connect all of your component's reset lines to the CPU, and add a pull-down (or sometimes a pull-up) resistor to those lines, all components will automatically stay in reset until the CPU starts and configures the related I/O pins as outputs.

• The software that runs on the main CPU should then bring all other components out of the reset state, step by step.
  This way, the software has full control over the hardware initialitation order. If a random racing condition is discovered later on, the software can be modified to avoid the problem.

• The software should be able to reset any single component at any point in time.
  It is not uncommon to design a device, ship thousands of units to customers all over the world, and then realise that some component has a hardware bug that makes it hang under certain conditions. Such hardware bugs are often listed in the corresponding errata sheet. The trouble is, some bugs are discovered months or even years later after a component is shipped, and some manufactures seem to hide their bugs by moving errata sheets to separate, hard-to-find documents. You may come across a component that works reliably if the input data makes sense and then occasionally freezes if connected to a noisy line that yields random input data every now and then. Or maybe your design proves to be incorrect and does not always meet some component's electrical requirements, making it hang every now and then.
  If the CPU can reset any single component, chances are that you can implement a software watchdog in order to alleviate the problem. The end user is never going to like coming across a short, random glicht in one of the device functions, but if the affected function is then quickly restored with a controlled, local reset, the glitch may be tolerable. It is hard to predict which component will fail and how many will need to be reset (and in what order) in order to restore the affected function, so do not skimp on reset lines. If you can only reset a group at a time, or just the whole device at once, chances are that a small, trivial glitch may render your device unusable for the customer.

Hardware Design Checklist

(Still to write)