shakti/m_class/gsoc2018.mdwn

   1 # Goal
   2
   3 The goal is to create, test and document a working pinmux (switchbox),
   4 with extended goals, time permitting, to add actual multiplexed peripherals
   5 to a pre-existing working core (lowRISC, ZipCPU, OR1k) and a further goal
   6 to get actual linux kernel drivers up and running.  This could be part
   7 of an existing team, or a single-person project, or a team project.
   8 All communication will be carried out on a public mailing list at all
   9 times, as part of the goal is to allow absolutely anyone to help if they
  10 feel so inclined.
  11
  12 # Details
  13
  14 Starting from a known-good working pre-existing SoC running well on
  15 a standard FPGA platform and having a few pre-existing proven
  16 peripherals working, the idea is to add a multiplexer so that the actual I/O
  17 pins can switch to different functions, just like any Embedded STM32F,
  18 or any Texas Instruments OMAP Series processor.
  19
  20 A pre-existing multiplexer already exists which may provide a good starting
  21 point: <https://github.com/wallento/pmod_switchbox>.  Another exists
  22 in the form of the SiFive "IOF":
  23 <https://github.com/sifive/freedom/blob/master/src/main/scala/everywhere/e300artydevkit/Platform.scala>
  24
  25 Additional peripherals
  26 in the form of PWM, UART, I2C, SPI, SD/MMC and RGB/TTL already exist on
  27 http://opencores.org so there will be no need to develop those.
  28
  29 If RISC-V is chosen (for example the lowRISC ethernet-0.5 branch
  30 <https://github.com/lowRISC/lowrisc-chip/tree/ethernet-v0.5>) then the
  31 first task will be to move the MicroSD and Ethernet peripherals aside
  32 and place the GPIO pinmux in between.  This should be a relatively
  33 straightforward task that on its own is a significant contribution,
  34 and the project could be declared to be a success even if this was the
  35 only task that was completed.
  36
  37 The next phase, where it gets interesting, would be to track down a suitable
  38 linux kernel driver for GPIO and rewrite it (or the pmod switchbox VHDL) to
  39 match precisely a pre-existing memory-mapped linux kernel GPIO driver.
  40 This would then need to be tested, demonstrating that the pins formerly
  41 used for MicroSD for example can now be switched to Input or Output.
  42
  43 The next phase after that, again if time permits, would be to incorporate
  44 further peripherals such as PWM, I2C, UART, SPI and others, as desired.
  45 Recommended priority here will be on saving time by tracking down code
  46 that already has pre-existing linux kernel drivers that match up with
  47 the associated Verilog / VHDL, so that time is not spent exclusively writing
  48 c code or exclusively writing Verilog / VHDL.
  49
  50 This project is therefore primarily about cross-skill integration and
  51 communication, and learning to work and collaborate "in the public eye",
  52 which takes either quite a lot of confidence, or just a particularly
  53 honest and open mind-set.
  54
  55 Skill level: varies from Beginner to Advanced.
  56
  57 Language / Tool: varied.  VHDL/Verilog/Chisel essential, c optional,
  58                  git, mailing lists, wikis, good written communication
  59                  skills in English absolutely essential.
  60
  61 Mentor: Luke Kenneth Casson Leighton, Stefan Wallentowitz.
  62
  63 # Notes
  64
  65 ## <https://lists.librecores.org/pipermail/discussion/2018-January/000406.html>
  66
  67 Some additional considerations:
  68
  69 Glitchless muxing::    Pads must never glitch when switched.
  70
  71 Request/Grant handshake::  Multiple requests can occur at the same time and control goes to the highest priority.
  72 A grant signal notifies the winner and losing input pads are driven to a specified value (1,0 ,other signal)
  73
  74 Fast path for main function::  The pads main function is the most important signal but it only controls the pad when no one
  75 else wants it. You want it one mux level from the pad and must not have to go through a bunch of muxes.
  76
  77 Jtag mode:: Boundary scan must test mission mode signals going to pad
  78
  79
  80 Test mode:: For any and all scan,mbist or test signals. Must not go through jtag Boundary scan.
  81
  82 Reset mode: Forces pad into reset state during power on reset
  83