cloud-email/mitmproxy - clone of mitm proxy

diff options

author	Maximilian Hils <git@maximilianhils.com>	2020-01-27 22:47:11 +0100
committer	GitHub <noreply@github.com>	2020-01-27 22:47:11 +0100
commit	9253a6c6a551c9dc776dafcccba086d45e669d6f (patch)
tree	8dc5e605e49b8ce68476d151b2060cfeadd17124 /libpathod/templates/docs_lang.html
parent	66fe6530631bae9371401f5a86cf4be797107e5c (diff)
parent	f5b76d6230d0e2a123b362348552b38ae463a8ca (diff)
download	mitmproxy-9253a6c6a551c9dc776dafcccba086d45e669d6f.tar.gz mitmproxy-9253a6c6a551c9dc776dafcccba086d45e669d6f.tar.bz2 mitmproxy-9253a6c6a551c9dc776dafcccba086d45e669d6f.zip

Merge pull request #3792 from beth92/patch-1

Update WSGI example

Diffstat (limited to 'libpathod/templates/docs_lang.html')

0 files changed, 0 insertions, 0 deletions

\chapter{Implementation Overview} \label{chapter:overview} Yosys is an extensible open source hardware synthesis tool. It is aimed at designers who are looking for an easily accessible, universal, and vendor-independent synthesis tool, as well as scientists who do research in electronic design automation (EDA) and are looking for an open synthesis framework that can be used to test algorithms on complex real-world designs. Yosys can synthesize a large subset of Verilog 2005 and has been tested with a wide range of real-world designs, including the OpenRISC 1200 CPU \citeweblink{OR1200}, the openMSP430 CPU \citeweblink{openMSP430}, the OpenCores I$^2$C master \citeweblink{i2cmaster} and the k68 CPU \citeweblink{k68}. As of this writing a Yosys VHDL frontend is in development. Yosys is written in C++ (using some features from the new C++11 standard). This chapter describes some of the fundamental Yosys data structures. For the sake of simplicity the C++ type names used in the Yosys implementation are used in this chapter, even though the chapter only explains the conceptual idea behind it and can be used as reference to implement a similar system in any language. \section{Simplified Data Flow} Figure~\ref{fig:Overview_flow} shows the simplified data flow within Yosys. Rectangles in the figure represent program modules and ellipses internal data structures that are used to exchange design data between the program modules. Design data is read in using one of the frontend modules. The high-level HDL frontends for Verilog and VHDL code generate an abstract syntax tree (AST) that is then passed to the AST frontend. Note that both HDL frontends use the same AST representation that is powerful enough to cover the Verilog HDL and VHDL language. The AST Frontend then compiles the AST to Yosys's main internal data format, the RTL Intermediate Language (RTLIL). A more detailed description of this format is given in the next section. There is also a text representation of the RTLIL data structure that can be parsed using the RTLIL Frontend. The design data may then be transformed using a series of passes that all operate on the RTLIL representation of the design. Finally the design in RTLIL representation is converted back to text by one of the backends, namely the Verilog Backend for generating Verilog netlists and the RTLIL Backend for writing the RTLIL data in the same format that is understood by the RTLIL Frontend. With the exception of the AST Frontend, which is called by the high-level HDL frontends and can't be called directly by the user, all program modules are called by the user (usually using a synthesis script that contains text commands for Yosys). By combining passes in different ways and/or adding additional passes to Yosys it is possible to adapt Yosys to a wide range of applications. For this to be possible it is key that (1) all passes operate on the same data structure (RTLIL) and (2) that this data structure is powerful enough to represent the design in different stages of the synthesis. \begin{figure}[t] \hfil \begin{tikzpicture} \tikzstyle{process} = [draw, fill=green!10, rectangle, minimum height=3em, minimum width=10em, node distance=15em] \tikzstyle{data} = [draw, fill=blue!10, ellipse, minimum height=3em, minimum width=7em, node distance=15em] \node[process] (vlog) {Verilog Frontend}; \node[process, dashed, fill=green!5] (vhdl) [right of=vlog] {VHDL Frontend}; \node[process] (ilang) [right of=vhdl] {RTLIL Frontend}; \node[data] (ast) [below of=vlog, node distance=5em, xshift=7.5em] {AST}; \node[process] (astfe) [below of=ast, node distance=5em] {AST Frontend}; \node[data] (rtlil) [below of=astfe, node distance=5em, xshift=7.5em] {RTLIL}; \node[process] (pass) [right of=rtlil, node distance=5em, xshift=7.5em] {Passes}; \node[process] (vlbe) [below of=rtlil, node distance=7em, xshift=-13em] {Verilog Backend}; \node[process] (ilangbe) [below of=rtlil, node distance=7em, xshift=0em] {RTLIL Backend}; \node[process, dashed, fill=green!5] (otherbe) [below of=rtlil, node distance=7em, xshift=+13em] {Other Backends}; \draw[-latex] (vlog) -- (ast); \draw[-latex] (vhdl) -- (ast); \draw[-latex] (ast) -- (astfe); \draw[-latex] (astfe) -- (rtlil); \draw[-latex] (ilang) -- (rtlil); \draw[latex-latex] (rtlil) -- (pass); \draw[-latex] (rtlil) -- (vlbe); \draw[-latex] (rtlil) -- (ilangbe); \draw[-latex] (rtlil) -- (otherbe); \end{tikzpicture} \caption{Yosys simplified data flow (ellipses: data structures, rectangles: program modules)} \label{fig:Overview_flow} \end{figure} \section{The RTL Intermediate Language} All frontends, passes and backends in Yosys operate on a design in RTLIL representation. The only exception are the high-level frontends that use the AST representation as an intermediate step before generating RTLIL data. In order to avoid reinventing names for the RTLIL classes, they are simply referred to by their full C++ name, i.e.~including the {\tt RTLIL::} namespace prefix, in this document. Figure~\ref{fig:Overview_RTLIL} shows a simplified Entity-Relationship Diagram (ER Diagram) of RTLIL. In $1:N$ relationships the arrow points from the $N$ side to the $1$. For example one RTLIL::Design contains $N$ (zero to many) instances of RTLIL::Module. A two-pointed arrow indicates a $1:1$ relationship. The RTLIL::Design is the root object of the RTLIL data structure. There is always one ``current design'' in memory which passes operate on, frontends add data to and backends convert to exportable formats. But in some cases passes internally generate additional RTLIL::Design objects. For example when a pass is reading an auxiliary Verilog file such as a cell library, it might create an additional RTLIL::Design object and call the Verilog frontend with this other object to parse the cell library. \begin{figure}[t] \hfil \begin{tikzpicture} \tikzstyle{entity} = [draw, fill=gray!10, rectangle, minimum height=3em, minimum width=7em, node distance=5em, font={\ttfamily}] \node[entity] (design) {RTLIL::Design}; \node[entity] (module) [right of=design, node distance=11em] {RTLIL::Module} edge [-latex] node[above] {\tiny 1 \hskip3em N} (design); \node[entity] (process) [fill=green!10, right of=module, node distance=10em] {RTLIL::Process} (process.west) edge [-latex] (module); \node[entity] (memory) [fill=red!10, below of=process] {RTLIL::Memory} edge [-latex] (module); \node[entity] (wire) [fill=blue!10, above of=process] {RTLIL::Wire} (wire.west) edge [-latex] (module); \node[entity] (cell) [fill=blue!10, above of=wire] {RTLIL::Cell} (cell.west) edge [-latex] (module); \node[entity] (case) [fill=green!10, right of=process, node distance=10em] {RTLIL::CaseRule} edge [latex-latex] (process); \node[entity] (sync) [fill=green!10, above of=case] {RTLIL::SyncRule} edge [-latex] (process); \node[entity] (switch) [fill=green!10, below of=case] {RTLIL::SwitchRule} edge [-latex] (case); \draw[latex-] (switch.east) -- ++(1em,0) |- (case.east); \end{tikzpicture} \caption{Simplified RTLIL Entity-Relationship Diagram} \label{fig:Overview_RTLIL} \end{figure} There is only one active RTLIL::Design object that is used by all frontends, passes and backends called by the user, e.g.~using a synthesis script. The RTLIL::Design then contains zero to many RTLIL::Module objects. This corresponds to modules in Verilog or entities in VHDL. Each module in turn contains objects from three different categories: \begin{itemize} \item RTLIL::Cell and RTLIL::Wire objects represent classical netlist data. \item RTLIL::Process objects represent the decision trees (if-then-else statements, etc.) and synchronization declarations (clock signals and sensitivity) from Verilog {\tt always} and VHDL {\tt process} blocks. \item RTLIL::Memory objects represent addressable memories (arrays). \end{itemize} \begin{sloppypar} Usually the output of the synthesis procedure is a netlist, i.e. all RTLIL::Process and RTLIL::Memory objects must be replaced by RTLIL::Cell and RTLIL::Wire objects by synthesis passes. \end{sloppypar} All features of the HDL that cannot be mapped directly to these RTLIL classes must be transformed to an RTLIL-compatible representation by the HDL frontend. This includes Verilog-features such as generate-blocks, loops and parameters. The following sections contain a more detailed description of the different parts of RTLIL and rationale behind some of the design decisions. \subsection{RTLIL Identifiers} All identifiers in RTLIL (such as module names, port names, signal names, cell types, etc.) follow the following naming convention: they must either start with a backslash (\textbackslash) or a dollar sign (\$). Identifiers starting with a backslash are public visible identifiers. Usually they originate from one of the HDL input files. For example the signal name ``{\tt \textbackslash sig42}'' is most likely a signal that was declared using the name ``{\tt sig42}'' in an HDL input file. On the other hand the signal name ``{\tt \$sig42}'' is an auto-generated signal name. The backends convert all identifiers that start with a dollar sign to identifiers that do not collide with identifiers that start with a backslash. This has three advantages: \begin{itemize} \item First, it is impossible that an auto-generated identifier collides with an identifier that was provided by the user. \item Second, the information about which identifiers were originally provided by the user is always available which can help guide some optimizations. For example the ``opt\_rmunused'' tries to preserve signals with a user-provided name but doesn't hesitate to delete signals that have auto-generated names when they just duplicate other signals. \item Third, the delicate job of finding suitable auto-generated public visible names is deferred to one central location. Internally auto-generated names that may hold important information for Yosys developers can be used without disturbing external tools. For example the Verilog backend assigns names in the form {\tt \_{\it integer}\_}. \end{itemize} Whitespace and control characters (any character with an ASCII code 32 or less) are not allowed in RTLIL identifiers; most frontends and backends cannot support these characters in identifiers. In order to avoid programming errors, the RTLIL data structures check if all identifiers start with either a backslash or a dollar sign, and contain no whitespace or control characters. Violating these rules results in a runtime error. All RTLIL identifiers are case sensitive. Some transformations, such as flattening, may have to change identifiers provided by the user to avoid name collisions. When that happens, attribute ``{\tt hdlname}`` is attached to the object with the changed identifier. This attribute contains one name (if emitted directly by the frontend, or is a result of disambiguation) or multiple names separated by spaces (if a result of flattening). All names specified in the ``{\tt hdlname}`` attribute are public and do not include the leading ``\textbackslash``. \subsection{RTLIL::Design and RTLIL::Module} The RTLIL::Design object is basically just a container for RTLIL::Module objects. In addition to a list of RTLIL::Module objects the RTLIL::Design also keeps a list of {\it selected objects}, i.e. the objects that passes should operate on. In most cases the whole design is selected and therefore passes operate on the whole design. But this mechanism can be useful for more complex synthesis jobs in which only parts of the design should be affected by certain passes. Besides the objects shown in the ER diagram in Fig.~\ref{fig:Overview_RTLIL} an RTLIL::Module object contains the following additional properties: \begin{itemize} \item The module name \item A list of attributes \item A list of connections between wires \item An optional frontend callback used to derive parametrized variations of the module \end{itemize} The attributes can be Verilog attributes imported by the Verilog frontend or attributes assigned by passes. They can be used to store additional metadata about modules or just mark them to be used by certain part of the synthesis script but not by others. Verilog and VHDL both support parametric modules (known as ``generic entities'' in VHDL). The RTLIL format does not support parametric modules itself. Instead each module contains a callback function into the AST frontend to generate a parametrized variation of the RTLIL::Module as needed. This


context:
space:
mode: