--- /dev/null
+#=======================================================================
+# Makefile for generating LaTeX documents
+#-----------------------------------------------------------------------
+#
+# This is a simple makefile for generating LaTeX documents. It will
+# run bibtex, generate eps from xfig figures, and make pdfs. The
+# makefile supports builds in non-source directories: just make a
+# build directory, copy the makefile there, and change the srcdir
+# variable accordingly.
+#
+# Note that the makefile assumes that the default dvips/ps2pdfwr
+# commands "do the right thing" for fonts in pdfs. This is true on
+# Athena/Linux and Fedora Core but is not true for older redhat installs ...
+#
+# At a minimum you should just change the main variable to be
+# the basename of your toplevel tex file. If you use a bibliography
+# then you should set the bibfile variable to be the name of your
+# .bib file (assumed to be in the source directory).
+#
+
+srcdir = ../src
+
+docs_with_bib = power-spec
+docs_without_bib =
+
+srcs = $(wildcard $(srcdir)/*.tex)
+figs = $(wildcard $(srcdir)/figs/*)
+bibs = $(srcdir)/power-spec.bib
+
+#=======================================================================
+# You shouldn't need to change anything below this
+#=======================================================================
+
+PDFLATEX := TEXINPUTS=$(srcdir): pdflatex -interaction=nonstopmode -halt-on-error
+BIBTEX := BIBINPUTS=$(srcdir): bibtex
+
+default : pdf
+
+#------------------------------------------------------------
+# PDF
+
+pdfs_with_bib = $(addsuffix .pdf, $(docs_with_bib))
+pdfs_without_bib = $(addsuffix .pdf, $(docs_without_bib))
+pdfs = $(pdfs_with_bib) $(pdfs_without_bib)
+
+pdf : $(pdfs)
+.PHONY: pdf open
+
+open: $(pdfs)
+ open $(pdfs)
+
+$(pdfs_with_bib): %.pdf: $(srcdir)/%.tex $(srcs) $(figs) $(bibs)
+ $(PDFLATEX) $*
+ $(BIBTEX) $*
+ $(PDFLATEX) $*
+ $(PDFLATEX) $*
+
+$(pdfs_without_bib): %.pdf: $(srcdir)/%.tex $(srcs) $(figs)
+ $(PDFLATEX) $*
+ $(PDFLATEX) $*
+
+junk += $(pdfs) *.aux *.log *.bbl *.blg *.toc *.out
+
+#------------------------------------------------------------
+# Other Targets
+
+clean :
+ rm -rf $(junk) *~ \#*
--- /dev/null
+%
+\chapter{Introduction}
+
+\section{Why has Libre-SOC chosen PowerPC ?}
+
+For a hybrid CPU-VPU-GPU, intended for mass-volume adoption in tablets,
+netbooks, chromebooks and industrial embedded (SBC) systems, our choice was
+between Nyuzi, MIAOW, RISC-V, PowerPC, MIPS and OpenRISC.
+
+Of all the options, the PowerPC architecture is more complete and far more
+mature. It also has a deeper adoption by Linux distributions.
+
+Following IBM's release of the Power Architecture instruction set to the Linux
+Foundation in August 2019 the barrier to using it is no more than that of using
+RISC-V. We are encouraged that the OpenPOWER Foundation is supportive of what
+we are doing and helping, e.g by putting us in touch with people who can help
+us.
+
+\subsection{Summary}
+
+\vspace{-0.1in}
+\begin{itemize}
+\parskip 0pt
+\itemsep 1pt
+
+\item
+ We propose the standardisation of the way that the PowerPC Instruction Set
+ Architecture (PPC ISA) is extended, enabling many different flavours within a
+ well supported family to co-exist, long-term, without conflict, right across
+ the board.
+
+\item
+
+ This is about more than just our project. Our proposals will facilitate the
+ use of PPC in novel or niche applications without breaking the PPC ISA into
+ incompatible islands.
+
+\item
+
+ PPC will gain a competitive market advantage by removing the need for
+ separate VPU or GPU functions in RTL or ASICs thus enabling lower cost
+ systems. Libre-SOC's project is to extend the PPC to integrate the GPU and
+ VPU functionality directly as part of the PPC ISA (example: Broadcom
+ VideoCore IV being based around extensions to an ARC core).
+
+\item
+
+ Libre-SOC's extensions will be easily adopted, as the standard GNU/Linux
+ distributions will very deliberately run unmodified on our ISA, including
+ full compatibility with illegal instruction trap requirements.
+
+\end{itemize}
+
+
+\subsection{One CPU multiple ISAs}
+
+This is a quick overview of the way that we would like to add changes that we
+are proposing to the PowerPC instruction set (ISA). It is based on a Open
+Standardisation of the way that existing "mode switches", already found in the
+POWER instruction set, are added:
+
+\begin{itemize}
+\parskip 0pt
+\itemsep 1pt
+
+\item
+
+ FPSCR's "NI" bit, setting non-IEEE754 FP mode
+
+\item
+
+ MSR's "LE" bit (and associated HILE bit), setting little-endian mode
+
+\item
+
+ MSR's "SF" bit, setting either 32-bit or 64-bit mode
+
+\item
+
+ PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
+
+\end{itemize}
+
+[It is well-noted that unless each "mode switch" bit is set, any alternative
+(additional) instructions (and functionality) are completely inaccessible, and
+will result in "illegal instruction" traps being thrown. This is recognised as
+being critically important.]
+
+These bits effectively create multiple, incompatible run-time switchable ISAs
+within one CPU. They are selectable for the needs of the individual program (or
+OS) being run.
+
+All of these bits are set by an instruction, that, once set, radically changes
+the entire behaviour and characteristics of subsequent instructions.
+
+With these (and other) long-established precedents already in POWER, there is
+therefore essentially conceptually nothing new about what we propose: we simply
+seek that the process by which such "switching" is added is formalised and
+standardised, such that we (and others, including IBM itself) have a clear,
+well-defined standards-non-disruptive, atomic and non-intrusive path to extend
+the POWER ISA for use in markets that it presently cannot enter.
+
+We advocate that some of "mode-setting" (escape-sequencing) bits be binary
+encoded, some unary encoded, and that some space marked for "offical" use, some
+"experimental", some "custom" and some "reserved". The available space in a
+suitably-chosen SPR to be formalised, and recommend the OpenPOWER Foundation be
+given the IANA-like role in atomically allocating mode bits.
+
+The IANA-like atomic role ensures that new PCR mode bits are allocated
+world-wide unique. In combination with a mandatory illegal instruction
+exception to be thrown on any system not supporting any given mode, the
+opportunity exists for all systems to trap and emulate all other systems and
+thus retain some semblance of interoperability. (Contrast this with either
+allocating the same mode bit(s) to two (or more) designers, or not making
+illegal exceptions mandatory: binary interoperability becomes unachievable and
+the result is irrevocable damage to POWER's reputation.)
+
+We also advocate to consider reserving some bits as a "countdown" where the new
+mode will be enabled only for a certain number of instructions. This avoids an
+explicit need to "flip back", reducing binary code size. Note that it is not a
+good idea to let the counter cross a branch or other change in PC (and to throw
+illegal instruction trap if attempted). However traps and exceptions themselves
+will need to save (and restore) the countdown, just as the rest of the PCR and
+other modeswitching bits need to be saved.
+
+Instructions that we need to add, which are a normal part of GPUs, include
+ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode (different from both
+IEEE754 and "NI" mode), and many more. Many of these may turn out to be useful
+in a wider context: they however need to be fully isolated behind
+"mode-setting" before being in any way considered for Standards-track formal
+adoption.
+
+Some mode-setting instructions are privileged, i.e can only be set by the
+kernel (e.g 32 or 64 bit mode). Most of the escape sequences that we propose
+will be (have to be) usable without the need for an expensive system call
+overhead (because some of the instructions needed will be in extremely tight
+inner loops).
+
+\subsection{About Libre-SOC Commercial Project}
+
+The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
+mass-volume production. There is no separate GPU, because the CPU is the GPU.
+There is no separate VPU, because the CPU is the GPU. There is not even a
+separate pipeline: the CPU pipelines are the GPU and VPU pipelines.
+
+Closest equivalents include the ARC core (which has VPU extensions and 3D
+extensions in the form of Broadcom's VideoCore IV) and the ICubeCorp IC3128.
+Both are considered "hybrid" CPU-GPU-VPU processors.
+
+"Normal" Commercial GPUs are entirely separate processors. The development cost
+and complexity purely in terms of Software Drivers alone is immense. We reject
+that approach (and as a small team we do not have the resources anyway).
+
+With the project being Libre - not proprietary and secretive and never to be
+published, ever - it is no good having the extensions as "custom" because
+"custom" is specifically for the cases where the augmented toolchain is never,
+under any circumstances, published and made public by the proprietary company
+(and would never be accepted upstream anyway). For business commercial reasons,
+Libre-SOC is the total opposite of this proprietary, secretive approach.
+
+Therefore, to meet our business objectives:
+
+\begin{itemize}
+\parskip 0pt
+\itemsep 1pt
+
+\item
+
+ As shown from Nyuzi and Larrabee, although ideally suited to high
+ performance compute tasks, a "traditional" general-purpose full
+ IEEE754-compliant Vector ISA (such as that in POWER9) is not an adequate
+ basis for a commercially competitive GPU. Nyuzi's conclusion is that using
+ such general-purpose Vector ISAs results in reaching only 25% performance
+ (or requiring 4-fold increase in power consumption) to achieve par with
+ current commercial-grade GPUs.
+
+\item
+
+ We are not going the "traditional" (separate custom GPU) route because it
+ is not practical for a new team to design hardware and spend 8+ man-years
+ on massively complex inter-processor driver development as well
+
+\item
+
+ We cannot meet our objectives with a "custom extension" because the
+ financial burden on our team to maintain a total hard fork of not just
+ toolchains, but also entire GNU/Linux Distros, is highly undesirable, and
+ completely impractical (we know for certain that Redhat would strongly
+ object to any efforts to hard-fork Fedora)
+
+\item
+
+ We could invent our own custom GPU instruction set (or use and extend an
+ existing one, to save a man-decade on toolchain development) however even
+ to switch over to that "Dual ISA" GPU instruction set in the next clock
+ cycle still requires a PCR modeswitch bit in order to avoid needing a full
+ Inter-Processor Bus Architecture like on "traditional" GPUs.
+
+\item
+
+ If extending any instruction set, rather than have a Dual ISA (which needs
+ the PCR modeswitch bit to access it) we would rather extend POWER.
+
+\item
+
+ We cannot "go ahead anyway" because to do so would be highly irresponsible
+ and cause massive disruption to the POWER community.
+
+\end{itemize}
+
+With all impractical options eliminated the only remaining responsible option
+is to extend the POWER ISA in an atomically-managed (IANA-style) formal
+fashion, whilst (critically and absolutely essentially) always providing a PCR
+compatibility mode that is fully POWER compliant, including all illegal
+instruction traps.
+
+
--- /dev/null
+% Package includes
+
+\usepackage{graphicx}
+\usepackage{geometry}
+\usepackage{array}
+\usepackage{colortbl}
+\usepackage[svgnames]{xcolor}
+
+\usepackage[colorlinks,citecolor=Navy,linkcolor=Navy]{hyperref}
+\usepackage{placeins}
+\usepackage{longtable}
+\usepackage{multirow}
+\usepackage{float}
+\usepackage{listings}
+\usepackage{comment}
+\usepackage{enumitem}
+\usepackage{verbatimbox}
+\usepackage{amsmath}
+
+\usepackage[olditem,oldenum]{paralist}
+
+% Setup margins
+
+\setlength{\topmargin}{-0.5in}
+\setlength{\textheight}{9in}
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\textwidth}{6.5in}
+
+% Useful macros
+
+\newcommand{\note}[1]{{\bf [ NOTE: #1 ]}}
+\newcommand{\fixme}[1]{{\bf [ FIXME: #1 ]}}
+\newcommand{\todo}[1]{\marginpar{\footnotesize #1}}
+
+\newcommand{\wunits}[2]{\mbox{#1\,#2}}
+\newcommand{\um}{\mbox{$\mu$m}}
+\newcommand{\xum}[1]{\wunits{#1}{\um}}
+\newcommand{\by}[2]{\mbox{#1$\times$#2}}
+\newcommand{\byby}[3]{\mbox{#1$\times$#2$\times$#3}}
+
+\newlength\savedwidth
+\newcommand\whline[1]{%
+ \noalign{%
+ \global\savedwidth\arrayrulewidth\global\arrayrulewidth 1.5pt%
+ }%
+ \cline{#1}%
+ \noalign{\vskip\arrayrulewidth}%
+ \noalign{\global\arrayrulewidth\savedwidth}%
+}
+
+% Custom list environments
+
+\newlist{tightlist}{itemize}{1}
+\setlist[tightlist]{label=\textbullet,nosep}
+
+\newenvironment{titledtightlist}[1]
+{\noindent
+ ~~\textbf{#1}
+ \begin{tightlist}}
+{\end{tightlist}}
+
+\newenvironment{commentary}
+{ \vspace{-1.5mm}
+ \list{}{
+ \topsep 0mm
+ \partopsep 0mm
+ \listparindent 1.5em
+ \itemindent \listparindent
+ \rightmargin \leftmargin
+ \parsep 0mm
+ }
+ \item
+ \small\em
+ \noindent\nopagebreak\rule{\linewidth}{1pt}\par
+ \noindent\ignorespaces
+}
+{\endlist}
+
+%\newenvironment{discussion}
+%{ \vspace{-1.5mm}
+% \list{}{
+% \topsep 0mm
+% \partopsep 0mm
+% \listparindent 1.5em
+% \itemindent \listparindent
+% \rightmargin \leftmargin
+% \parsep 0mm
+% }
+% \item
+% \small\em
+% \noindent\nopagebreak\rule{\linewidth}{1pt}\par
+% \noindent\textbf{Discussion:}
+%}
+%{\endlist}
+
+% Other commands and parameters
+
+\pagestyle{myheadings}
+\setlength{\parindent}{0in}
+\setlength{\parskip}{10pt}
+\sloppy
+\raggedbottom
+\clubpenalty=10000
+\widowpenalty=10000
+
+% Commands for register format figures.
+
+% New column types to use in tabular environment for instruction formats.
+% Allocate 0.18in per bit.
+\newcolumntype{I}{>{\centering\arraybackslash}p{0.18in}}
+% Two-bit centered column.
+\newcolumntype{W}{>{\centering\arraybackslash}p{0.36in}}
+% Three-bit centered column.
+\newcolumntype{F}{>{\centering\arraybackslash}p{0.54in}}
+% Four-bit centered column.
+\newcolumntype{Y}{>{\centering\arraybackslash}p{0.72in}}
+% Five-bit centered column.
+\newcolumntype{R}{>{\centering\arraybackslash}p{0.9in}}
+% Six-bit centered column.
+\newcolumntype{S}{>{\centering\arraybackslash}p{1.08in}}
+% Seven-bit centered column.
+\newcolumntype{O}{>{\centering\arraybackslash}p{1.26in}}
+% Eight-bit centered column.
+\newcolumntype{E}{>{\centering\arraybackslash}p{1.44in}}
+% Ten-bit centered column.
+\newcolumntype{T}{>{\centering\arraybackslash}p{1.8in}}
+% Twelve-bit centered column.
+\newcolumntype{M}{>{\centering\arraybackslash}p{2.2in}}
+% Sixteen-bit centered column.
+\newcolumntype{K}{>{\centering\arraybackslash}p{2.88in}}
+% Twenty-bit centered column.
+\newcolumntype{U}{>{\centering\arraybackslash}p{3.6in}}
+% Twenty-bit centered column.
+\newcolumntype{L}{>{\centering\arraybackslash}p{3.6in}}
+% Twenty-five-bit centered column.
+\newcolumntype{J}{>{\centering\arraybackslash}p{4.5in}}
+
+\newcommand{\instbit}[1]{\mbox{\scriptsize #1}}
+\newcommand{\instbitrange}[2]{~\instbit{#1} \hfill \instbit{#2}~}
+\newcommand{\reglabel}[1]{\hfill {\tt #1}\hfill\ }
+
+\newcommand{\wiri}{\textbf{WIRI}}
+\newcommand{\wpri}{\textbf{WPRI}}
+\newcommand{\wlrl}{\textbf{WLRL}}
+\newcommand{\warl}{\textbf{WARL}}
+
+\newcommand{\unspecified}{\textsc{unspecified}}
projects / libresoc-isa-manual.git / commitdiff