Progress on Pinmux, IO Pads, and JTAG Boundary scan (Temporary page)

(This is a temporary page for organising current work on the above.)

Links:

The tasks initially set out by Luke in 2019 (bug 50 description):

  • peripheral multiplexing
  • SoC-to-peripheral interconnect auto-generation
  • auto-creation of peripheral memory-address locations and suitable linux header
  • auto-creation of linux kernel header files for GPIO pinmux layout
  • auto-creation of IO ring corona for ASICs
  • auto-generation and allocation of IRQs and IRQ connectivity
  • auto-generation of Technical Reference Manual sections

Definitions

Useful definitions required for understanding the undertaken tasks. See the main page for more indepth explanation on IO Pads, JTAG.

JTAG Boundary Scan (BS) chain

Essentially a combination of a multiplexer and shift register. The BS chain allows core signals to connect straight to the ASIC pads, or allow an external JTAG device to individually control the core inputs and pad outputs via the shift register.

Core

Refers to peripherals coming from the ASIC (I2C, SPI, UART, GPIO, etc.). Core signals come from the the actual HDL of the peripherals, and connect to the JTAG Boundary Scan chain.

Pad/s

Refers to the ASIC pads which are routed out to the outside world. These pads are what a chip user can interact with directly (for good or bad...).

Pinmux

Pin multiplexer allows ASIC pads to support a range of functions (although only one at a time per pad). Each function is allocated to a "bank", and the selected bank can be configured by the user.

A pinmux is an absolute must when the amount of functionality (or peripheral signals) greatly exceed the available number of pins on a package. Also, pinmuxing allows to select packages with smaller pincounts, thus producing cheaper (and higher yield) chips.

For example: A pad can be I2C SDA on bank0, a GPIO on bank1, a UART RX on bank2. By setting the bank select to 1, the pad can act as a GPIO (input or output).

Progress on code in "testing_stage1.py":

Dummy pinset

A test pinset that specifies which peripherals are to be added. In this case, four GPIOs, one UART, one I2C.

Resource signal creation

"create_resources()" function parses a given pinset (the dummy one in this case), and creates a resources list containing the peripherals (with nmigen subsignals such as sda, gpio_o/i/oe etc.).

Within this function, Resource.family(), JTAGResource(), UARTResource(), I2CResource() create the signals with correct direction (input/output/inout).

The returned "resources" list is used in....?

Blinker test module

Contains a JTAG module from Chips4Makers (c4m-jtag). The JTAG module is the backbone of the Blinker test module, because from it the Boundary Scan chain is produced.

By using "jtag.request('i2c')" (or 'uart', 'gpio', etc.), the Boundary Scan chain is extended. The JTAG module then provides subsignals to connect to core as well as pad side.

I2C and UART are connected in a loopback configuration (input to output), allowing to test both signals at the same time. The GPIO output is an XOR of the GPIO input, and a test input controlled by sim (gpio_o_test). The oe signals are controlled by the sim using test input registers.

ASIC Platform

Performs some magic with file template code. Resource list (dummy pinset) provided at instantiation is added to the internal resource list (?). More magic with configuring pins that are inputs/outputs/tristates. Core/Pad pins are connected to the appropriate JTAG pins.

Unit tests

GPIO test

For every output configuration of four GPIOs (16), go through each input configuration. Assert that signal states match the function in the Blinker class.

UART test

Check TX matches RX when high and low.

I2C test

Check SDA out and SCL out match SDA/SCL in. Check oe's by driving the test registers.

JTAG test BS chain

The unit test has four test cases, two before the peripherals are exercised, and two after:

  1. Send 0xFFFFF via TDI in EX_TEST mode
  2. Send 0xFFFFF via TDO in BS_SAMPLE mode
  3. Send 0x00000 via TDI in EX_TEST mode
  4. Send 0x00000 via TDI in BS_SAMPLE mode

The expected results are:

  1. All core outputs high (as these set by JTAG BS), all pad inputs low (not asserted yet)
  2. All signals should be low (as JTAG TDI is ignored and all inputs low).
  3. All pad inputs and sim controlled input (output enables etc.) should be high.
  4. All signals should be high.

These test cases are performed by the "jtag_unit_test" with selected JTAG instructions (SAMPLE or EXTEST), data to send via TDI, and expected TDO data vector. The TDO and TDI data is compared using asserts.

NOTE: Currently the last test case's TDO data does not match the actual core/pad signal values. Not sure why the returned TDO is incorrect, however the signals are correct.

Pinmux GPIO Block Testing and Simulation

Sim commands for single GPIO - IN PROGRESS

  • gpio_config - Set the CSR (only the first GPIO is currently configured).
  • gpio_rd_csr - Read the current CSR state and parse (only first GPIO).
  • gpio_rd_input - Read the current input.
  • gpio_set_out - Set the output to given value.
  • gpio_set_in_pad - Set the input signals for the block (external, not controlled by WB)
  • gpio_rd_out - (TODO)

Test

The current test does the following:

  • Set the bank select to a random value between 0 and 15 (unless the "use_random" argument is set to false)
  • Set oe (all GPIOs are outputs)
  • Set GPIO outputs sequentially
  • Set external GPIO inputs sequentially and clear

Yosys Diagram visualisation

(TODO)