shakti/m_class/pinmux.mdwn

   1 # Pin Multiplexing
   2
   3 * <http://bugs.libre-riscv.org/show_bug.cgi?id=8>
   4 * <https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/>
   5   includes GPIO, SPI, UART, JTAG, I2C, PinCtrl, UART and PWM.  Also included
   6   is a Watchdog Timer and others.
   7 * <https://github.com/sifive/freedom/blob/master/src/main/scala/everywhere/e300artydevkit/Platform.scala>
   8   Pinmux ("IOF") for multiplexing several I/O functions onto a single pin
   9
  10 Complex!
  11
  12 # Requirements
  13
  14 "to create a general-purpose libre-licensed pinmux
  15 module that can be used with a wide range of interfaces that have
  16 Open-Drain, Push-Push *and bi-directional* capabilities, as well as
  17 optional pull-up and pull-down resistors, in an IDENTICAL fashion to
  18 that of ALL major well-known embedded SoCs from ST Micro, Cypress,
  19 Texas Instruments, NXP, Rockchip, Allwinner and many many others".
  20
  21 ## Analysis
  22
  23 Questions:
  24
  25 * Can damage occur by outputs being short-circuited to outputs in any way?
  26   A partial analysis showed that because outputs are one-to-many, there should
  27   not be a possibility for that to occur.  However what if a function is
  28   bi-directional?
  29 * Is de-bouncing always needed on every input?  Is it ok for de-bouncing
  30   to be only done on EINT?
  31
  32
  33 # Pinouts Specification
  34
  35 Covered in [[pinouts]].  The general idea is to target several
  36 distinct applications and, by trial-and-error, create a pinmux table that
  37 successfully covers all the target scenarios by providing absolutely all
  38 required functions for each and every target.  A few general rules:
  39
  40 * Different functions (SPI, I2C) which overlap on the same pins on one
  41  bank should also be duplicated on completely different banks, both from
  42  each other and also the bank on which they overlap.  With each bank having
  43  separate Power Domains this strategy increases the chances of being able
  44  to place low-power and high-power peripherals and sensors on separate
  45  GPIO banks without needing external level-shifters.
  46 * Functions which have optional bus-widths (eMMC: 1/2/4/8) may have more
  47  functions overlapping them than would otherwise normally be considered.
  48 * Then the same overlapped high-order bus pins can also be mapped onto
  49  other pins.  This particularly applies to the very large buses, such
  50  as FlexBus (over 50 pins).  However if the overlapped pins are on a
  51  different bank it becomes necessary to have both banks run in the same
  52  GPIO Power Domain.
  53 * All functions should really be pin-muxed at least twice, preferably
  54  three times.  Four or more times on average makes it pointless to
  55  even have four-way pinmuxing at all, so this should be avoided.
  56  The only exceptions (functions which have not been pinmuxed multiple
  57  times) are the RGB/TTL LCD channel, and both ULPI interfaces.
  58
  59 # GPIO Pinmux Power Domains
  60
  61 Of particular importance is the Power Domains for the GPIO.  Realistically
  62 it has to be flexible (simplest option: recommended to be between
  63 1.8v and 3.3v) as the majority of low-cost mass-produced sensors and
  64 peripherals on I2C, SPI, UART and SD/MMC are at or are compatible with
  65 this voltage range.  Long-tail (older / stable / low-cost / mass-produced)
  66 peripherals in particular tend to be 3.3v, whereas newer ones with a
  67 particular focus on Mobile tend to be 1.2v to 1.8v.
  68
  69 A large percentage of sensors and peripherals have separate IO voltage
  70 domains from their main supply voltage: a good example is the SN75LVDS83b
  71 which has one power domain for the RGB/TTL I/O, one for the LVDS output,
  72 and one for the internal logic controller (typical deployments tend not
  73 to notice the different power-domain capability, as they usually supply all
  74 three voltages at 3.3v).
  75
  76 Relying on this capability, however, by selecting a fixed voltage for
  77 the entire SoC's GPIO domain, is simply not a good idea: all sensors
  78 and peripherals which do not have a variable (VREF) capability for the
  79 logic side, or coincidentally are not at the exact same fixed voltage,
  80 will simply not be compatible if they are high-speed CMOS-level push-push
  81 driven.  Open-Drain on the other hand can be handled with a MOSFET for
  82 two-way or even a diode for one-way depending on the levels, but this means
  83 significant numbers of external components if the number of lines is large.
  84
  85 So, selecting a fixed voltage (such as 1.8v or 3.3v) results in a bit of a
  86 problem: external level-shifting is required on pretty much absolutely every
  87 single pin, particularly the high-speed (CMOS) push-push I/O.  An example: the
  88 DM9000 is best run at 3.3v.  A fixed 1.8v FlexBus would
  89 require a whopping 18 pins (possibly even 24 for a 16-bit-wide bus)
  90 worth of level-shifting, which is not just costly
  91 but also a huge amount of PCB space: bear in mind that for level-shifting, an
  92 IC with **double** the number of pins being level-shifted is required.
  93
  94 Given that level-shifting is an unavoidable necessity, and external
  95 level-shifting has such high cost(s), the workable solution is to
  96 actually include GPIO-group level-shifting actually on the SoC die,
  97 after the pin-muxer at the front-end (on the I/O pads of the die),
  98 on a per-bank basis.  This is an extremely common technique that is
  99 deployed across a very wide range of mass-volume SoCs.
 100
 101 One very useful side-effect for example of a variable Power Domain voltage
 102 on a GPIO bank containing SD/MMC functionality is to be able to change the
 103 bank's voltage from 3.3v to 1.8v, to match an SD Card's capabilities, as
 104 permitted under the SD/MMC Specification.  The alternative is to be forced to
 105 deploy an external level-shifter IC (if PCB space and BOM target allows) or to
 106 fix the voltage at 3.3v and thus lose access to the low-power and higher-speed
 107 capabilities of modern SD Cards.
 108
 109 In summary: putting level shifters right at the I/O pads of the SoC, after
 110 the pin-mux (so that the core logic remains at the core voltage) is a
 111 cost-effective solution that can have additional unintended side-benefits
 112 and cost savings beyond simply saving on external level-shifting components
 113 and board space.
 114