(no commit message)

[libreriscv.git] / 22nm_PowerPI.mdwn

# Introduction

This is a page describing a proposed mass-volume SoC.  It outlines:

* the NREs involved (realistically USD $7m, with headroom up to $12m preferred)
* proposes a fair market price (around $12-13)
* estimates a manufacturing cost (around $3.50 to $4)
* realistic industry-standard timescales (12-18 months).

On that basis it indicates that commercial viability is possible if the
quantities ordered are over 1 million units.
Several ways in which the NREs may be covered in order to be viable include:

* VC investors (typically requires multiple LOIs and customer committments)
* European Union Grants (such as [SiPearl](https://www.eenewsanalog.com/news/european-processor-startup-gets-eu62-million-kickstart-grant) and the [EPI](https://www.european-processor-initiative.eu/dissemination-material/epi-consortium-members-list/) )
* Direct OEM / Customer investment (pre-orders, in effect)

With enough direct customers, VC funding may not even be needed.  This is
a preferred route that is not unreasonable and has been achieved before
in the Silicon Industry.

**This is a POWER PI proposal, but why was the Raspberry Pi successful?**

As a dedicated Set-Top Box / IPTV solution, the initial Pi processor,
the 700 mhz ARM11 BCM2835, was only available from Broadcomm in
Minimum Order  Quantities (MOQ) of 5 million and above.  As a
specialist Vertical Market Applications Processor, it was *not
available* for use in products on the general market.

The *only reason*
that it went into the Raspberry Pi at all (selling in far smaller quantities) was because Eben Upton was an employee of Broadcom and had access to NDA'd internal datasheets.  Crucially: on
learning that it was to be deployed in an Educational market, Broadcom
could not exactly say "no".

In the intervening years, despite persistent requests on Pi Forums,
even efforts by the Raspberry Pi Foundation themselves to see a non-Broadcom processor
be developed and deployed have not been successful because a Pi-only-centric
processor does not have a large enough market share to justify the NREs.

**The lesson here is that a low-cost processor must cover multiple markets
to be successful**.

Consequently the Libre-SOC "POWER Pi" is designed to enter multiple
disparate large-volume markets: the Educational and Open aspects
may thus be considered an essential part of the P.R. rather than as
major sales opportunities.

# Specs for 22/28nm SOC

**Overall goal: an SoC that is capable of meeting multiple markets:**

* Basic "Pi" style SBC role (aka POWER-Pi)
  - Power consumption to be **strictly** limited to under 3.5 watts
    so as to be passively-cooled and significantly reduce OEM product costs,
    as well as increase reliability
* Libre-style smartphone, tablet, netbook and chromebook products
  - Pine64, Purism, FairPhone, many others
  - 3.5 watt limit greatly simplifies portable product development,
    as well as increasing battery life
* Baseboard Management Controller (BMC) replacement for existing BMC products
  - including PCIe Video Card capability after BMC Boot
* Mid-end low-cost Graphics Card with reasonable 3D and VPU capabilities
  - This as a sub-goal of the BMC functionality (stand-alone)

By meeting the needs of multiple markets in a single SoC the product has
broader appeal yet amortises the NREs across all of them.  This is
industry-standard practice: ST Micro and ATMEL use the exact same die in
up to 12-14 different products.

**Three different pin packages:**

* 400-450 pin FBGA 18mm 0.8mm and 14mm 0.6mm pitch
  - single 32-bit DDR3/4 interface (appx 120 pins incl. VSS/VDD)
  - Suitable for smaller products.
  - 0.8mm pitch is easier for low-cost China PCB manufacturing
  - This lesson is learned from Freescale's 19-year-LTS iMX6 SoC
* 600-650 pin FBGA appx 20mm 0.6mm pitch
  - dual 32-bit DDR3/4 interfaces.
  - Suitable for 4k HD resolution screens and Graphics Card capability.

By re-packaging the same die in different FPGA packages it meets the
needs of different markets without significant NREs.  Texas Instruments
and Freescale/NXP and many other companies follow this practice.

**Timeframe from when funding is received:**

* 6-8 months for PHY negotiation and supply by IP Vendors (DDR4 is always
  custom-tailored by the supplier)
* 6-8 months development (in parallel with PHY negotiation)
* 3-4 months FPGA proof-of-concept (partial overlap with above)
* 4-6 months layout development once design is frozen (partial overlap with
  above)

Total: 12-18 months development time.  **This is industry-standard**

**NREs:**

These are ballpark estimates:

* USD 250,000 for layout software licensing (Cadence / Synopsis / Mentor)
* USD 400,000 for engineer to perform layout to GDS-II
* USD 1,000,000 for (LP)DDR3/4 which includes customisation by IP vendor
* USD 250,000 for Libre-licensed DDR firmware (normally closed binary)
* USD 250,000 for USB3/C
* USD 250,000 for HDMI PHY (includes HDCP closed firmware: DVI may be better)
* USD 50,000 for PCIe PHY
* USD 50,000 for RGMII Ethernet PHY
* USD 50,000 for Libre-licensed PCIe firmware (normally closed binary)
* USD 2,000,000 for Software and Hardware Engineers
* USD 2,000,000 for 22nm Production Masks (1,000,000 for 28nm)
* USD 200,000 per 22nm MPW Shuttle Service (test ASICs.  28nm is 100,000)
* USD 200,000 estimated for other PHYs (UART, SD/MMC, I2C, SPI)

Total is around USD 7 million.

Note that this is a bare minimum and may require re-spins of the production
masks.  A safety margin is recommended to cover at least 2 additional
re-spins.  Business Operating costs bring the total realistically
to around USD 12 million.

Production cost is expected to be around the $3.50 to $4 mark meaning
that a sale price of around $12-$13 will require **1 million units**
sold to recover the NREs.

**Even if the SoC used an off-the-shelf OpenPOWER core or a lower
functionality core without GPU or VPU capability these development
NREs are still required**

# Functionality

 - 4 Core SMP dual-issue LibreSOC OpenPOWER CPU
 - SimpleV Capability with VPU and GPU Instructions *no need for separate GPU*
 - IOMMU
 - PCIe Host Controller
 - PCIe Slave controller (RaptorCS wants to use LibreSOC as a Graphics Card
    on their TALOS-II motherboards)
 - BMC capability (OpenBMC / LibreBMC) - enables LibreSOC to replace the
   closed source existing market BMC product range, booting up large servers
   securely
 - RGB/TTL framebuffer VGA/LCD PHY from Richard Herveille, RoaLogic.
 - Pinmux for mapping multiple I/O functions to pins (standard fare
   for SoCs, to reduce pincount)
 - SD/MMC and eMMC
 - Standard "Pi / Arduino" SoC-style interfaces including UART, I2C,
   SPI, GPIO, PWM, EINT, AC97.

The "PI / Arduino" style interfaces are provided so as to be pin-comoatibke with the existing "Shield" 3rd party producy markets.

# Interfaces

Much of the advanced section is "under consideration" because there are proprietary firmware issues involved as well as high power consumption and high costs involved.  OpenCAPI for example would, in 22nm, at 25 ghz, be an enormous power draw (IBM used 14nm for the POWER9 25ghz SERDES)

HDCP is present in HDMI, as well as being optional in eDP and by extension USB-C as well.  Licensing of any of these Controllers therefore introduces the risk of closed firmware which will be viewed unfavourably by the educational markets, libre/open supporters and advocates, as well as cause Customer Support issues and introduce security vulnerabilities that *cannot be fixed or evaluated*.

Great care therefore needs to be taken in selecting the advanced interfaces.

## Advanced

 - SERDES - 10rx, 14tx
   - 4tx, 4rx for [OMI(DDR4](https://openpowerfoundation.org/wp-content/uploads/2018/10/Jeff-Steuchli.OpenCAPI-OPS-OMI.pdf) on top of SERDES with OpenCAPI protocol) @25GHz
   - 4tx, 4rx for PCIe and other CAPI devices
   - 3tx for HDMI (note: requires HDMI Trademark Licensing and Compliance Testing.  DVI is an alternative)
 - USB-OTG / USB2 - [Luna USB](https://github.com/greatscottgadgets/luna)
with [USB3300 PHY](https://www.microchip.com/wwwproducts/en/USB3300#datasheet-toggle) (Tested max at 333MB/s with Luna on ECP5)
 - [[shakti/m_class/USB3]]

## Basic

 - [OpenFSI](https://openpowerfoundation.org/?resource_lib=field-replaceable-unit-fru-service-interface-fsi-openfsi-specification) instead of / as well as JTAG
  - [Raptor HDL](https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga)
  - [Raptor Libsigrok](https://gitlab.raptorengineering.com/raptor-engineering-public/dsview/-/tree/master/libsigrokdecode4DSL/decoders/fsi)

These should be easily doable with LiteX.

* [[shakti/m_class/UART]]
* [[shakti/m_class/JTAG]]
* [[shakti/m_class/I2C]]
* [[shakti/m_class/GPIO]]
* [[shakti/m_class/SPI]]
* [[shakti/m_class/QSPI]]
* [[shakti/m_class/LPC]] - BMC Management
* [[shakti/m_class/EINT]]
* [[shakti/m_class/PWM]]
* [[shakti/m_class/RGBTTL]] in conjunction with:
  - TI TFP410a (DVI / HDMI)
  - Chrontel converter (DVI, eDP, VGA)
  - Solomon SSD2828 (MIP)
  - TI SN75LVDS83b (LVDS)

# Protocols
 - IMPI over i2c to talk to the BMC
   - [Intel Spec Sheet](https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/second-gen-interface-spec-v2.pdf)
   - [RaptorCS HDL](https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga/blob/master/ipmi_bt_slave.v)
 - Reset Vector is set Flexver address over LPC
   - [Whitepaper](https://www.raptorengineering.com/TALOS/documentation/flexver_intro.pdf)

# Notes

* closed source BMC when web-enabled is a high value hacking target