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 * <https://bitbucket.org/casl/pinmux.git> - implementation by Shakti RISE Group
  10
  11 Surprisingly complex!
  12
  13 # Requirements
  14
  15 "to create a general-purpose libre-licensed pinmux
  16 module that can be used with a wide range of interfaces that have
  17 Open-Drain, Push-Push *and bi-directional* capabilities, as well as
  18 optional pull-up and pull-down resistors, in an IDENTICAL fashion to
  19 that of ALL major well-known embedded SoCs from ST Micro, Cypress,
  20 Texas Instruments, NXP, Rockchip, Allwinner and many many others".
  21
  22 * The IO pad shall have pull-up enable, pull-down enable, variable
  23   frequency de-bounce (schmidt trigger), tri-state capability,
  24   variable current drive (on input), Open Drain and CMOS Push-Push.
  25 * Certain functions shall have the ability to control whether
  26   IO pads will be input or output (not the GPIO registers).
  27 * Number of wires shall be minimised especially in cases where
  28   the IO pad (puen, oe) need to change under the control of the
  29   function (not the GPIO registers).
  30 * The amount of latency (gates in between I/O pad and function)
  31   shall be minimised
  32 * There shall be no short-circuits created by multiple input
  33   pins trying to drive the same input function
  34 * There shall be no short-circuits even when functions control
  35   when the IO pad is an input.
  36
  37 ## Analysis
  38
  39 Questions:
  40
  41 * Can damage occur (to the ASIC) by outputs being short-circuited to outputs
  42   in any way?
  43   A partial analysis showed that because outputs are one-to-many, there should
  44   not be a possibility for that to occur.  However what if a function is
  45   bi-directional?
  46 * Is de-bouncing always needed on every input?  Is it ok for de-bouncing
  47   to be only done on EINT?
  48 * Can the input mux be turned round and "selector" logic added so that
  49   there is no possibility of damage to inputs?
  50
  51 # Images
  52
  53 * [[mygpiomux.jpg]]
  54
  55 # GSoC2018
  56
  57 Introductions:
  58
  59 * Luke Kenneth Casson Leighton (lkcl) - reverse-engineer, software libre
  60   advocate, assembly-level programming and disassembly, python, c, c++,
  61   gate-level circuit and ASIC design, PCB design and assembly, 3D CAD design,
  62   lots of different stuff.  Guardian of the EOMA68 Certification Mark,
  63   and currently responsible for coordinating the design of a fully Libre
  64   RISC-V SoC in collaboration with the RISE Group, IIT Madras, Shakti Project.
  65   not much experience at verilog (have done a couple of tutorials).
  66 * Xing GUO(xing) - undergraduate (3rd year) from Southeast
  67   University, EE student, C/C++, Python, Verilog, assembly (not very proficient),
  68   Haskell (not very proficient). RTL design, server maintenance.
  69   E-mail: higuoxing at gmail dot com, Github: [Higuoxing](https://github.com/higuoxing) some of my projects are there :)
  70 * Aurojyoti Das(auro) - graduate student (MSc Electrical - Microelectronics)
  71   at TU Delft, Netherlands. C/C++, Verilog, VHDL, SystemVerilog, RTL Design,
  72   Logic Verification, Python/Perl/Shell scripting, Analog IC Design (currently learning)
  73
  74 Hardware available:
  75
  76 * lkcl: ZC706
  77 * xing: zynq-7020 and Xilinx XC7A100T-484
  78
  79 # Discussion and Links
  80
  81 * <https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf>
  82 * <https://lists.librecores.org/pipermail/discussion/2018-February/thread.html>
  83 * <https://lists.librecores.org/pipermail/discussion/2018-January/000404.html>
  84
  85 # Some Useful Resource
  86 * <https://github.com/ucb-bar/generator-bootcamp> Interactive tutorial on Scala and Chisel (best one, take it, trust me!)
  87 * <https://docs.scala-lang.org/tour/tour-of-scala.html> A brief Scala tutorial
  88 * <https://github.com/ucb-bar/chisel-tutorial> A brief Chisel tutorial
  89 * <https://github.com/xfguo/tbgen/blob/master/tbgen.py> auto-generated test module for verilog
  90 * <https://github.com/kdurant/verilog-testbench> described here <https://www.vim.org/scripts/script.php?script_id=4596>
  91
  92 # Pinouts Specification
  93
  94 Covered in [[pinouts]].  The general idea is to target several
  95 distinct applications and, by trial-and-error, create a pinmux table that
  96 successfully covers all the target scenarios by providing absolutely all
  97 required functions for each and every target.  A few general rules:
  98
  99 * Different functions (SPI, I2C) which overlap on the same pins on one
 100  bank should also be duplicated on completely different banks, both from
 101  each other and also the bank on which they overlap.  With each bank having
 102  separate Power Domains this strategy increases the chances of being able
 103  to place low-power and high-power peripherals and sensors on separate
 104  GPIO banks without needing external level-shifters.
 105 * Functions which have optional bus-widths (eMMC: 1/2/4/8) may have more
 106  functions overlapping them than would otherwise normally be considered.
 107 * Then the same overlapped high-order bus pins can also be mapped onto
 108  other pins.  This particularly applies to the very large buses, such
 109  as FlexBus (over 50 pins).  However if the overlapped pins are on a
 110  different bank it becomes necessary to have both banks run in the same
 111  GPIO Power Domain.
 112 * All functions should really be pin-muxed at least twice, preferably
 113  three times.  Four or more times on average makes it pointless to
 114  even have four-way pinmuxing at all, so this should be avoided.
 115  The only exceptions (functions which have not been pinmuxed multiple
 116  times) are the RGB/TTL LCD channel, and both ULPI interfaces.
 117
 118 # GPIO Pinmux Power Domains
 119
 120 Of particular importance is the Power Domains for the GPIO.  Realistically
 121 it has to be flexible (simplest option: recommended to be between
 122 1.8v and 3.3v) as the majority of low-cost mass-produced sensors and
 123 peripherals on I2C, SPI, UART and SD/MMC are at or are compatible with
 124 this voltage range.  Long-tail (older / stable / low-cost / mass-produced)
 125 peripherals in particular tend to be 3.3v, whereas newer ones with a
 126 particular focus on Mobile tend to be 1.2v to 1.8v.
 127
 128 A large percentage of sensors and peripherals have separate IO voltage
 129 domains from their main supply voltage: a good example is the SN75LVDS83b
 130 which has one power domain for the RGB/TTL I/O, one for the LVDS output,
 131 and one for the internal logic controller (typical deployments tend not
 132 to notice the different power-domain capability, as they usually supply all
 133 three voltages at 3.3v).
 134
 135 Relying on this capability, however, by selecting a fixed voltage for
 136 the entire SoC's GPIO domain, is simply not a good idea: all sensors
 137 and peripherals which do not have a variable (VREF) capability for the
 138 logic side, or coincidentally are not at the exact same fixed voltage,
 139 will simply not be compatible if they are high-speed CMOS-level push-push
 140 driven.  Open-Drain on the other hand can be handled with a MOSFET for
 141 two-way or even a diode for one-way depending on the levels, but this means
 142 significant numbers of external components if the number of lines is large.
 143
 144 So, selecting a fixed voltage (such as 1.8v or 3.3v) results in a bit of a
 145 problem: external level-shifting is required on pretty much absolutely every
 146 single pin, particularly the high-speed (CMOS) push-push I/O.  An example: the
 147 DM9000 is best run at 3.3v.  A fixed 1.8v FlexBus would
 148 require a whopping 18 pins (possibly even 24 for a 16-bit-wide bus)
 149 worth of level-shifting, which is not just costly
 150 but also a huge amount of PCB space: bear in mind that for level-shifting, an
 151 IC with **double** the number of pins being level-shifted is required.
 152
 153 Given that level-shifting is an unavoidable necessity, and external
 154 level-shifting has such high cost(s), the workable solution is to
 155 actually include GPIO-group level-shifting actually on the SoC die,
 156 after the pin-muxer at the front-end (on the I/O pads of the die),
 157 on a per-bank basis.  This is an extremely common technique that is
 158 deployed across a very wide range of mass-volume SoCs.
 159
 160 One very useful side-effect for example of a variable Power Domain voltage
 161 on a GPIO bank containing SD/MMC functionality is to be able to change the
 162 bank's voltage from 3.3v to 1.8v, to match an SD Card's capabilities, as
 163 permitted under the SD/MMC Specification.  The alternative is to be forced to
 164 deploy an external level-shifter IC (if PCB space and BOM target allows) or to
 165 fix the voltage at 3.3v and thus lose access to the low-power and higher-speed
 166 capabilities of modern SD Cards.
 167
 168 In summary: putting level shifters right at the I/O pads of the SoC, after
 169 the pin-mux (so that the core logic remains at the core voltage) is a
 170 cost-effective solution that can have additional unintended side-benefits
 171 and cost savings beyond simply saving on external level-shifting components
 172 and board space.
 173