X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=shakti%2Fm_class%2Fpinmux.mdwn;h=967dc6918d07f657015b832d7738ad9afc3fd5a8;hb=b6190ae1f9d5703a77167049b741a8353d5e5dd8;hp=0258c57095a8c6d3ad46d543878c85bcd3eab632;hpb=708f0ff2991ccd4e855435607f99071b267e43ff;p=libreriscv.git

diff --git a/shakti/m_class/pinmux.mdwn b/shakti/m_class/pinmux.mdwn
index 0258c5709..967dc6918 100644
--- a/shakti/m_class/pinmux.mdwn
+++ b/shakti/m_class/pinmux.mdwn
@@ -6,6 +6,7 @@
   is a Watchdog Timer and others.
 * <https://github.com/sifive/freedom/blob/master/src/main/scala/everywhere/e300artydevkit/Platform.scala>
   Pinmux ("IOF") for multiplexing several I/O functions onto a single pin
+* <https://bitbucket.org/casl/pinmux.git> - implementation by Shakti RISE Group
 
 Surprisingly complex!  
 
@@ -13,20 +14,25 @@ Surprisingly complex!
 
 "to create a general-purpose libre-licensed pinmux
 module that can be used with a wide range of interfaces that have
-Open-Drain, Push-Push *and bi-directional* capabilities, as well as
+Open-Drain, Push-Pull *and bi-directional* capabilities, as well as
 optional pull-up and pull-down resistors, in an IDENTICAL fashion to
 that of ALL major well-known embedded SoCs from ST Micro, Cypress,
 Texas Instruments, NXP, Rockchip, Allwinner and many many others".
 
-* Number of wires shall be minimised especially in cases where
-  outputs need to change characteristics of the IO pad (puen, oe)
-* There shall be no short-circuits created by multiple input
-  pins trying to drive the same input function
 * The IO pad shall have pull-up enable, pull-down enable, variable
-  frequency de-bounce, tri-state capability, Open Drain and CMOS
-  Push-Push.
+  frequency de-bounce (schmidt trigger), tri-state capability, 
+  variable current drive (on input), Open Drain and CMOS Push-Pull.
+* Certain functions shall have the ability to control whether
+  IO pads will be input or output (not the GPIO registers).
+* Number of wires shall be minimised especially in cases where
+  the IO pad (puen, oe) need to change under the control of the
+  function (not the GPIO registers).
 * The amount of latency (gates in between I/O pad and function)
   shall be minimised
+* There shall be no short-circuits created by multiple input
+  pins trying to drive the same input function
+* There shall be no short-circuits even when functions control
+  when the IO pad is an input.
 
 ## Analysis
 
@@ -57,10 +63,6 @@ Introductions:
   and currently responsible for coordinating the design of a fully Libre
   RISC-V SoC in collaboration with the RISE Group, IIT Madras, Shakti Project.
   not much experience at verilog (have done a couple of tutorials).
-* Xing GUO(xing) - undergraduate (3rd year) from Southeast
-  University, EE student, C/C++, Python, Verilog, assembly (not very proficient), 
-  Haskell (not very proficient). RTL design, server maintenance.
-  E-mail: higuoxing at gmail dot com, Github: [Higuoxing](https://github.com/higuoxing) some of my projects are there :)
 * Aurojyoti Das(auro) - graduate student (MSc Electrical - Microelectronics) 
   at TU Delft, Netherlands. C/C++, Verilog, VHDL, SystemVerilog, RTL Design, 
   Logic Verification, Python/Perl/Shell scripting, Analog IC Design (currently learning) 
@@ -68,7 +70,7 @@ Introductions:
 Hardware available:
 
 * lkcl: ZC706
-* xing: zynq-7020 and Xilinx XC7A100T-484
+* xing: zynq-7020 and Xilinx XC7A100T-484 if needed contact him! <higuoxing@gmail.com>
 
 # Discussion and Links
 
@@ -76,10 +78,14 @@ Hardware available:
 * <https://lists.librecores.org/pipermail/discussion/2018-February/thread.html>
 * <https://lists.librecores.org/pipermail/discussion/2018-January/000404.html>
 
-## Some Useful Resource
-
+# Some Useful Resource
+* <https://github.com/ucb-bar/generator-bootcamp> Interactive tutorial on Scala and Chisel (best one, take it, trust me!)
 * <https://docs.scala-lang.org/tour/tour-of-scala.html> A brief Scala tutorial
 * <https://github.com/ucb-bar/chisel-tutorial> A brief Chisel tutorial
+* <https://github.com/xfguo/tbgen/blob/master/tbgen.py> auto-generated test module for verilog
+* <https://github.com/kdurant/verilog-testbench> described here <https://www.vim.org/scripts/script.php?script_id=4596>
+* <http://agilesoc.com/open-source-projects/svunit/> - SVunit - unit testing for verilog
+* [FPGA Overview](http://www.springer.com/cda/content/document/cda_downloaddocument/9781461435938-c2.pdf?SGWID=0-0-45-1333135-p174308376) Useful in writing GPIO related codes...
 
 # Pinouts Specification
 
@@ -128,14 +134,14 @@ Relying on this capability, however, by selecting a fixed voltage for
 the entire SoC's GPIO domain, is simply not a good idea: all sensors
 and peripherals which do not have a variable (VREF) capability for the
 logic side, or coincidentally are not at the exact same fixed voltage,
-will simply not be compatible if they are high-speed CMOS-level push-push
+will simply not be compatible if they are high-speed CMOS-level push-pull
 driven.  Open-Drain on the other hand can be handled with a MOSFET for
 two-way or even a diode for one-way depending on the levels, but this means
 significant numbers of external components if the number of lines is large.
 
 So, selecting a fixed voltage (such as 1.8v or 3.3v) results in a bit of a
 problem: external level-shifting is required on pretty much absolutely every
-single pin, particularly the high-speed (CMOS) push-push I/O.  An example: the
+single pin, particularly the high-speed (CMOS) push-pull I/O.  An example: the
 DM9000 is best run at 3.3v.  A fixed 1.8v FlexBus would
 require a whopping 18 pins (possibly even 24 for a 16-bit-wide bus)
 worth of level-shifting, which is not just costly