* 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.
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
* 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
+* [[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
-
-<https://opencores.org/project,vga_lcd> full linux kernel driver also available
-
-## SPI
-
-* APB to SPI <https://opencores.org/project,apb2spi>
-* ASIC-proven <https://opencores.org/project,spi_master_slave>
-* Wishbone-compliant <https://opencores.org/project,simple_spi>
-
-## SD/MMC (including eMMC)
-
-* <https://opencores.org/project,sd_mmc_emulator>
-* (needs work) <https://opencores.org/project,sdcard_mass_storage_controller>
-
-# 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]]
-
projects / libreriscv.git / blobdiff