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 # Simple GPIO extension
  80 The code from soc repo was taken and is being extended to support full gpio capability