docs/pinmux/temp_pinmux_info.mdwn

   1 # Progress on Pinmux, IO Pads, and JTAG Boundary scan (Temporary page)
   2 (This is a temporary page for organising current work on the above.)
   3
   4 Links:
   5
   6 * Main page on pinmux: [[/docs/pinmux]]
   7 * <https://bugs.libre-soc.org/show_bug.cgi?id=50>
   8 * <https://git.libre-soc.org/?p=c4m-jtag.git>
   9 * <https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/bus/simple_gpio.py;hb=HEAD>
  10 * <https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/testing_stage1.py;hb=HEAD>
  11 * <https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/simple_gpio.py;hb=HEAD>
  12
  13 The tasks initially set out by Luke in 2019 (bug 50 description):
  14
  15 * peripheral multiplexing
  16 * SoC-to-peripheral interconnect auto-generation
  17 * auto-creation of peripheral memory-address locations and suitable linux header
  18 * auto-creation of linux kernel header files for GPIO pinmux layout
  19 * auto-creation of IO ring corona for ASICs
  20 * auto-generation and allocation of IRQs and IRQ connectivity
  21 * auto-generation of Technical Reference Manual sections
  22
  23 # Definitions
  24 Useful definitions required for understanding the undertaken tasks.
  25 See the main page for more indepth explanation on IO Pads, JTAG.
  26
  27 ## JTAG Boundary Scan (BS) chain
  28 Essentially a combination of a multiplexer and shift register.
  29 The BS chain allows core signals to connect straight to the ASIC pads,
  30 or allow an external JTAG device to individually control the core inputs
  31 and pad outputs via the shift register.
  32 ## Core
  33 Refers to peripherals coming from the ASIC (I2C, SPI, UART, GPIO, etc.).
  34  Core signals come from the the actual HDL of the peripherals,
  35 and connect to the JTAG Boundary Scan chain.
  36 ## Pad/s
  37 Refers to the ASIC pads which are routed out to the outside world.
  38 These pads are what a chip user can interact with directly (for good or bad...).
  39 ## Pinmux
  40 Pin multiplexer allows ASIC pads to support a range of functions
  41 (although only one at a time per pad).
  42 Each function is allocated to a "bank", and the selected bank
  43 can be configured by the user.
  44
  45 A pinmux is an absolute must when the amount of functionality
  46 (or peripheral signals) greatly exceed the available number
  47 of pins on a package.
  48 Also, pinmuxing allows to select packages with smaller pincounts,
  49 thus producing cheaper (and higher yield) chips.
  50
  51 For example: A pad can be I2C SDA on bank0, a GPIO on bank1,
  52 a UART RX on bank2. By setting the bank select to 1,
  53 the pad can act as a GPIO (input or output).
  54
  55 # Progress on code in "testing_stage1.py":
  56 ## Dummy pinset
  57 A test pinset that specifies which peripherals are to be added.
  58 In this case, four GPIOs, one UART,  one I2C.
  59
  60 ## Resource signal creation
  61 "create_resources()" function parses a given pinset
  62 (the dummy one in this case), and creates a resources list containing
  63 the peripherals (with nmigen subsignals such as sda, gpio_o/i/oe etc.).
  64
  65 Within this function, Resource.family(), JTAGResource(), UARTResource(),
  66 I2CResource() create the signals with correct direction (input/output/inout).
  67
  68 The returned "resources" list is used in....?
  69
  70 ## Blinker test module
  71 Contains a JTAG module from Chips4Makers (c4m-jtag).
  72 The JTAG module is the backbone of the Blinker test module,
  73 because from it the Boundary Scan chain is produced.
  74
  75 By using "jtag.request('i2c')" (or 'uart', 'gpio', etc.),
  76 the Boundary Scan chain is extended. The JTAG module then provides subsignals
  77 to connect to core as well as pad side.
  78
  79 I2C and UART are connected in a loopback configuration (input to output),
  80 allowing to test both signals at the same time. The GPIO output is an XOR of
  81 the GPIO input, and a test input controlled by sim (gpio_o_test).
  82 The oe signals are controlled by the sim using test input registers.
  83
  84 ## ASIC Platform
  85 Performs some magic with file template code.
  86 Resource list (dummy pinset) provided at instantiation is added to the internal
  87 resource list (?).
  88 More magic with configuring pins that are inputs/outputs/tristates.
  89 Core/Pad pins are connected to the appropriate JTAG pins.
  90
  91 ## Unit tests
  92 ### GPIO test
  93 For every output configuration of four GPIOs (16), go through each input
  94 configuration.
  95 Assert that signal states match the function in the Blinker class.
  96
  97 ### UART test
  98 Check TX matches RX when high and low.
  99
 100 ### I2C test
 101 Check SDA out and SCL out match SDA/SCL in.
 102 Check oe's by driving the test registers.
 103
 104 ### JTAG test BS chain
 105 The unit test has four test cases, two before the peripherals are exercised,
 106 and two after:
 107
 108 1. Send 0xFFFFF via TDI in EX_TEST mode
 109 1. Send 0xFFFFF via TDO in BS_SAMPLE mode
 110 1. Send 0x00000 via TDI in EX_TEST mode
 111 1. Send 0x00000 via TDI in BS_SAMPLE mode
 112
 113 The expected results are:
 114
 115 1. All core outputs high (as these set by JTAG BS), all pad inputs low
 116 (not asserted yet)
 117 1. All signals should be low (as JTAG TDI is ignored and all inputs low).
 118 1. All pad inputs and sim controlled input (output enables etc.) should be high.
 119 1. All signals should be high.
 120
 121 # Simple GPIO extension
 122 The code from soc repo was taken and is being extended to support full gpio capability
 123 TODO