X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=shakti%2Fm_class.mdwn;h=03dd71f6e1e97c749bd0b92510dd32b0425a6575;hb=778e2c7762c06d077b1ce75e941e181f9eb2232c;hp=4bf065d0aa191dbeb7399f7aa088d24b9c51ff73;hpb=3fe36080967c51713e3c09fe1a3a55528e66f3ad;p=libreriscv.git diff --git a/shakti/m_class.mdwn b/shakti/m_class.mdwn index 4bf065d0a..03dd71f6e 100644 --- a/shakti/m_class.mdwn +++ b/shakti/m_class.mdwn @@ -10,6 +10,7 @@ yields. * 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. @@ -24,6 +25,15 @@ to be used (8-10mil) and 4-5mil tracks with 4mil clearance. For details see +[[shakti_libre_riscv.jpg]] + +## Die area estimates + +* +* 40nm 64-bit rocket single-core single-issue in-order: 0.14mm^2 +* 40nm 16-16k L1 caches, 0.25mm^2 +* + ## Targetting full Libre Licensing to the bedrock. The only barrier to being able to replicate the masks from scratch @@ -98,14 +108,18 @@ firmly a priority focus. * 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 @@ -114,7 +128,7 @@ firmly a priority focus. ## 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 @@ -168,6 +182,11 @@ image acceleration, scalable fonts, and Z-buffering and much more. * MIAOW: ATI-compatible shader engine * 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 +* OpenShader +* GPLGPU +* FlexGripPlus ### Video encode / decode @@ -189,136 +208,56 @@ TBD # 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: +* * includes GPIO, SPI, UART, JTAG, I2C, PinCtrl, UART and PWM. Also included is a Watchdog Timer and others. * 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 - - full linux kernel driver also available - -## SPI - -* APB to SPI -* ASIC-proven -* Wishbone-compliant - -## SD/MMC (including eMMC) - -* -* (needs work) - -# 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. +* + 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 @@ -408,10 +347,24 @@ and accurate PLL clock timing provided, it may become possible to bit-bang and software-emulate high-speed interfaces such as SATA, HDMI, PCIe and many more. +# Testing + +* cocotb +* cocotb AXI4 stream interface + # Research (to investigate) +* LPC Interface * * * 110nm DDR3 PHY +* myhdl HDL cores +* B Extension proposal +* Bit-extracts +* Bit-reverse +* Bit-permutations +* Commentary on Micro-controller +* P-SIMD + +> [[!tag cpus]] -