* See [[pinouts]] for auto-generated table of pinouts (including mux)
* See [[peripheralschematics]] for example Reference Layouts
* See [[ramanalysis]] for a comprehensive analysis of why DDR3 is to be used.
+* See [[todo]] for a rough list of tasks (and link to bugtracker)
## Rough specification.
Quad-core 28nm RISC-V 64-bit (RISCV64GC core with Vector SIMD Media / 3D
-extensions), 300-pin 15x15mm BGA 0.8mm pitch, 32-bit DDR3/DDR3L/LPDDR3
+extensions), 300-pin 15x15mm BGA 0.8mm pitch, 32-bit DDR3-4/LPDDR3/4
memory interface and libre / open interfaces and accelerated hardware
functions suitable for the higher-end, low-power, embedded, industrial
and mobile space.
details see
<http://processors.wiki.ti.com/index.php/General_hardware_design/BGA_PCB_design>
+[[shakti_libre_riscv.jpg]]
+
+## Die area estimates
+
+* <http://hwacha.org/papers/riscv-esscirc2014-talk.pdf>
+* 40nm 64-bit rocket single-core single-issue in-order: 0.14mm^2
+* 40nm 16-16k L1 caches, 0.25mm^2
+* <http://people.csail.mit.edu/beckmann/publications/tech.../grain_size_tr_feb_2010.pdf>
+
## Targetting full Libre Licensing to the bedrock.
The only barrier to being able to replicate the masks from scratch
is the proprietary cells (e.g. memory cells) designed by the Foundries:
there is a potential long-term strategy in place to deal with that issue.
-The only proprietary interface utilised in the entire SoC is the DDR3
+The only proprietary interface utilised in the entire SoC is the DDR3/4
PHY plus Controller, which will be replaced in a future revision, making
the entire SoC exclusively designed and made from fully libre-licensed
BSD and LGPL openly and freely accessible VLSI and VHDL source.
In addition, no proprietary firmware whatsoever will be required to
operate or boot the device right from the bedrock: the entire software
stack will also be libre-licensed (even for programming the initial
-proprietary DDR3 PHY+Controller)
+proprietary DDR3/4 PHY+Controller)
# Inspiration from several sources
* SD/MMC for external MicroSD
* SD/MMC for on-PCB eMMC (care needed on power/boot sequence)
* NAND Flash (not recommended), requires 8080/ATI-style Bus with dedicated CS#
-* Optional 4-wire SPI NAND/NOR for boot (XIP - Execute In-place - recommended).
-* Audio over I2S (5-pin: 4 for output, 1 for input), fall-back to USB Audio
+* Optional 4-wire [[QSPI]] NAND/NOR for boot (XIP - Execute In-place - recommended).
+* Audio over [[I2S]] (5-pin: 4 for output, 1 for input), fall-back to USB Audio
+* Audio also over [[AC97]]
* Some additional SPI peripherals, e.g. connection to low-power MCU.
* GPIO (EINT-capable, with wakeup) for buttons, power, volume etc.
* Camera(s) either by CSI-1 (parallel CSI) or better by USB
* I2C sensors: accelerometer, compass, etc. Each requires EINT and RST GPIO.
* Capacitive Touchpanel (I2C and also requiring EINT and RST GPIO)
* Real-time Clock (usually an I2C device but may be on-board a support MCU)
+* [[PCIe]] via PXPIPE
+* [[LPC]] from Raptor Engineering
+* [[USB3]]
## Peripherals unique to laptop market
## Peripherals common to laptop and Industrial Market
-* Ethernet (RGMII or better 8080-style XT/AT/ATI MCU bus)
+* Ethernet ([[RGMII]] or better 8080-style XT/AT/ATI MCU bus for e.g. DM9000)
## Augmentation by an embedded MCU
* MIAOW: ATI-compatible shader engine <http://miaowgpu.org/>
* ORSOC GPU contains some primitives that can be used
* SIMD RISC-V extensions can obviate the need for a "full" separate GPU
+* Nyuzi (OpenMP, based on Intel Larabee Compute Engine)
+* Rasteriser <https://github.com/jbush001/ChiselGPU/tree/master/hardware>
+* OpenShader <https://git.code.sf.net/p/openshader/code>
+* GPLGPU <https://github.com/asicguy/gplgpu>
+* FlexGripPlus <https://github.com/Jerc007/Open-GPGPU-FlexGrip->
### Video encode / decode
# Proposed Interfaces
+* Plain [[GPIO]] multiplexed with a [[pinmux]] onto (nearly) all other pins
* RGB/TTL up to 1440x900 @ 60fps, 24-bit colour
-* 2x 1-lane SPI
-* 1x 4-lane (quad) SPI
+* 2x 1-lane [[SPI]]
+* 1x 4-lane (quad) [[QSPI]]
* 4x SD/MMC (1x 1/2/4/8-bit, 3x 1/2/4-bit)
-* 2x full UART incl. CTS/RTS
-* 3x UART (TX/RX only)
+* 2x full [[UART]] incl. CTS/RTS
+* 3x [[UART]] (TX/RX only)
* 3x [[I2C]] (in case of address clashes between peripherals)
* 8080-style AT/XT/ATI MCU Bus Interface, with multiple (8x CS#) lines
-* 3x PWM-capable GPIO
-* 32x EINT-cable GPIO with full edge-triggered and low/high IRQ capability
+* 3x [[PWM]]-capable GPIO
+* 32x [[EINT]]-cable GPIO with full edge-triggered and low/high IRQ capability
* 1x [[I2S]] audio with 4-wire output and 1-wire input.
-* 3x USB2 (ULPI for reduced pincount) each capable of USB-OTG support
-* DDR3/DDR3L/LPDDR3 32-bit-wide memory controller
+* 3x [[USB2]] ([[ULPI]] for reduced pincount) each capable of USB-OTG support
+* [[DDR]] DDR3/DDR3L/LPDDR3 32-bit-wide memory controller
+* [[JTAG]] for debugging
Some interfaces at:
+* <https://github.com/RoaLogic/apb4_gpio>
* <https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/>
includes GPIO, SPI, UART, JTAG, I2C, PinCtrl, UART and PWM. Also included
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
-
-## I2C
-
-At its own page [[I2C]]
-
-## I2S
-
-At its own page [[I2S]]
-
-## FlexBus
-
-At its own page [[FlexBus]]
-
-## RGB/TTL interface
-
-At its own page [[RGBTTL]]
-
-## SPI
-
-At its own page [[SPI]]
-
-## SD/MMC (including eMMC)
-
-At its own page [[sdmmc]]
-
-# Pin Multiplexing
-
-Complex! Covered in [[pinouts]]. The general idea is to target several
-distinct applications and, by trial-and-error, create a pinmux table that
-successfully covers all the target scenarios by providing absolutely all
-required functions for each and every target. A few general rules:
-
-* Different functions (SPI, I2C) which overlap on the same pins on one
- bank should also be duplicated on completely different banks, both from
- each other and also the bank on which they overlap. With each bank having
- separate Power Domains this strategy increases the chances of being able
- to place low-power and high-power peripherals and sensors on separate
- GPIO banks without needing external level-shifters.
-* Functions which have optional bus-widths (eMMC: 1/2/4/8) may have more
- functions overlapping them than would otherwise normally be considered.
-* Then the same overlapped high-order bus pins can also be mapped onto
- other pins. This particularly applies to the very large buses, such
- as FlexBus (over 50 pins). However if the overlapped pins are on a
- different bank it becomes necessary to have both banks run in the same
- GPIO Power Domain.
-* All functions should really be pin-muxed at least twice, preferably
- three times. Four or more times on average makes it pointless to
- even have four-way pinmuxing at all, so this should be avoided.
- The only exceptions (functions which have not been pinmuxed multiple
- times) are the RGB/TTL LCD channel, and both ULPI interfaces.
-
-## GPIO Pinmux Power Domains
-
-Of particular importance is the Power Domains for the GPIO. Realistically
-it has to be flexible (simplest option: recommended to be between
-1.8v and 3.3v) as the majority of low-cost mass-produced sensors and
-peripherals on I2C, SPI, UART and SD/MMC are at or are compatible with
-this voltage range. Long-tail (older / stable / low-cost / mass-produced)
-peripherals in particular tend to be 3.3v, whereas newer ones with a
-particular focus on Mobile tend to be 1.2v to 1.8v.
-
-A large percentage of sensors and peripherals have separate IO voltage
-domains from their main supply voltage: a good example is the SN75LVDS83b
-which has one power domain for the RGB/TTL I/O, one for the LVDS output,
-and one for the internal logic controller (typical deployments tend not
-to notice the different power-domain capability, as they usually supply all
-three voltages at 3.3v).
-
-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
-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
-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
-but also a huge amount of PCB space: bear in mind that for level-shifting, an
-IC with **double** the number of pins being level-shifted is required.
-
-Given that level-shifting is an unavoidable necessity, and external
-level-shifting has such high cost(s), the workable solution is to
-actually include GPIO-group level-shifting actually on the SoC die,
-after the pin-muxer at the front-end (on the I/O pads of the die),
-on a per-bank basis. This is an extremely common technique that is
-deployed across a very wide range of mass-volume SoCs.
-
-One very useful side-effect for example of a variable Power Domain voltage
-on a GPIO bank containing SD/MMC functionality is to be able to change the
-bank's voltage from 3.3v to 1.8v, to match an SD Card's capabilities, as
-permitted under the SD/MMC Specification. The alternative is to be forced to
-deploy an external level-shifter IC (if PCB space and BOM target allows) or to
-fix the voltage at 3.3v and thus lose access to the low-power and higher-speed
-capabilities of modern SD Cards.
-
-In summary: putting level shifters right at the I/O pads of the SoC, after
-the pin-mux (so that the core logic remains at the core voltage) is a
-cost-effective solution that can have additional unintended side-benefits
-and cost savings beyond simply saving on external level-shifting components
-and board space.
+* <https://bitbucket.org/casl/c-class/src/0e77398a030bfd705930d0f1b8b9b5050d76e265/src/peripherals/?at=master>
+ including AXI, DMA, GPIO, I2C, JTAG, PLIC, QSPI, SDRAM, UART (and TCM?).
+ FlexBus, HyperBus and xSPI to be added.
+
+List of Interfaces:
+
+* [[CSI]]
+* [[DDR]]
+* [[JTAG]]
+* [[I2C]]
+* [[I2S]]
+* [[PWM]]
+* [[EINT]]
+* [[FlexBus]]
+* LCD / RGB/TTL [[RGBTTL]]
+* [[SPI]]
+* [[QSPI]]
+* SD/MMC and eMMC [[sdmmc]]
+* Pin Multiplexing [[pinmux]]
+* Gigabit Ethernet [[RGMII]]
+* SDRAM [[sdram]]
+
+List of Internal Interfaces:
+
+* [[AXI]]
+* [[wishbone]]
# Items requiring clarification, or proposals TBD
and software-emulate high-speed interfaces such as SATA, HDMI, PCIe and
many more.
+# Testing
+
+* cocotb
+* <https://github.com/aoeldemann/cocotb> cocotb AXI4 stream interface
+
# Research (to investigate)
+* LPC Interface <https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga>
* <https://level42.ca/projects/ultra64/Documentation/man/pro-man/pro25/index25.1.html>
* <http://n64devkit.square7.ch/qa/graphics/ucode.htm>
* <https://dac.com/media-center/exhibitor-news/synopsys%E2%80%99-designware-universal-ddr-memory-controller-delivers-30-percent> 110nm DDR3 PHY
+* <https://bitbucket.org/cfelton/minnesota> myhdl HDL cores
+* B Extension proposal <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/zi_7B15kj6s>
+* Bit-extracts <https://github.com/cliffordwolf/bextdep>
+* Bit-reverse <http://programming.sirrida.de/bit_perm.html#general_reverse_bits>
+* Bit-permutations <http://programming.sirrida.de/bit_perm.html#c_e>
+* Commentary on Micro-controller <https://github.com/emb-riscv/specs-markdown/blob/develop/improvements-upon-privileged.md>
+* P-SIMD <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/vYVi95gF2Mo>
+
+>
[[!tag cpus]]
-