chapter15 - PacoReinaCampo/MPSoC-RISCV GitHub Wiki

IMPLEMENTATION

.. ....... ........ ........ ....... .. ........... ...... .... .. ...... ..... .. ..... .... ........ ... ...... . ... .... .. ......... ........... .... .... ........ .. .... . ..... ....... .... ... ........ .... ............ .. ... ... ....... .. ...... .... ... .... ....... .. ..... ... .... ....... ... ....... ......... ..... .......... ....... ..... ....... ... ....... ... ....... ..... ..... .... . ........ .. ... ..... ......... .. ........ ..... ....... .......... .......... ... ........ .. ... ..... .. ........ ..... .......... .... ... ...... .. .....

IMPLEMENTATION PROCESS

The implementation process uses the detailed design data to produce the hardware item that is an input to the testing activity.

Implementation Objectives

The objectives of the implementation process are:

A hardware item is produced which implements the hardware detailed design using representative manufacturing processes.
The hardware item implementation, assembly and installation data is complete.
Derived requirements are fed back to the detailed design process or other appropriate processes.
Requirement omissions and errors are provided to the appropriate processes for resolution.

Implementation Activities

Guidance for the implementation activities includes:

A hardware item should be produced using the design data and, where practical, the resources intended for the production product. This may include procurement, kitting, build, inspection and test.
Derived requirements generated by the implementation process should be fed back to the detailed design process or other appropriate processes.
Omissions and errors discovered during the implementation process should be provided to the appropriate process for resolution.

PRODUCTION TRANSITION PROCESS

In this process, manufacturing data, test facilities and general resources should be examined to ensure availability and suitability for production. The production transition process uses the outputs from the implementation and verification processes to move the product into production.

Production Transition Objectives

The objectives of this process are:

A baseline is established that includes all design and manufacturing data needed to support the consistent replication of the hardware item.
Manufacturing requirements related to safety are identified and documented and manufacturing controls are established.
Derived requirements are fed back to the implementation process or other appropriate processes.
Errors and omissions are provided to the appropriate processes for resolution.

Production Transition Activities

Guidance for the production transition activities includes:

Manufacturing data should be prepared from configured design data.
Manufacturing data should be checked for completeness and consistency with the configured design data.

Note: It is beyond the scope of this document to impose any conditions on the nature of the manufacturing build documentation.
Any changes or improvements that are incorporated during the production transition process should be evaluated to ensure they adhere to all product requirements, especially safety requirements. Any changes not compliant with customer or certification requirements should be approved by the relevant parties.
Manufacturing requirements pertaining to safety should be explicitly defined so they can be controlled during the production process.
Data required to develop acceptance test criteria should be determined.
Omissions or errors that are identified should be provided to the appropriate process for resolution.

ACCEPTANCE TEST

An acceptance test demonstrates that the manufactured, modified or repaired product performs in compliance with the key attributes of the unit on which certification is based. These key attributes are chosen using engineering judgement and are indicative that the product is capable of meeting the requirements to which the unit was developed.

Note 1: Configuration control of the "as built" product is not a function to be performed by the acceptance test activity. The configuration management plan, as described in Section 7 of this document, should describe how the applicant plans to perform this activity.

The scope of this document does include the determination of the acceptance test criteria, including pass/fail conditions. Production activities, including acceptance testing, are considered to be outside the scope of this document

Note 2: An acceptance test is not intended to verify all requirements on each production unit.

Subitem testing may be used as a part of the acceptance test.

Acceptance test criteria should ensure that:

Electrical tests are identified.
Environmental screening tests are identified when necessary.
The acceptance test provides coverage of those design aspects necessary to meet the safety requirements. Safety related item or subitems that are not covered by the test should be identified and other assurance means provided. These means may include analysis, design control, statistical process control or other means as appropriate.

SERIES PRODUCTION

This process is not within the scope of this document, but elements impacting design assurance are briefly described to complete the life cycle.

This process reproduces the hardware item on a routine basis that complies with the production data and requirements.

Considerations include:

Management of change of the production processes or the design provides assurance that change does not adversely impact existing safety or certification or compliance to the requirements.

Note: In addition to the guidance proposed by the body of the document, Section 11.1.1 covers Modifications to Previously Developed Hardware. When addressing component obsolescence, refer to Section 11.2.
Updating of all documentation related to changes is performed in compliance with approved configuration management plans.

Advanced Workflow {width=8cm}

MODEL

State Space Model {width=8cm}

${\dot {x} (t) = {A} (t) {x} (t) + {B} (t) {u} (t)}$

${ {y} (t) = {C} (t) {x} (t) + {D} (t) {u} (t)}$

HARDWARE/SOFTWARE DESIGN

IMPLEMENTATION

Architecture

Hardware Workflow {width=6cm}

A. FRONT-END ENGINEERING

1. System Level (SystemC/SystemVerilog)

The System Level abstraction of a system only looks at its biggest building blocks like processing units or peripheral devices. At this level the circuit is usually described using traditional programming languages like SystemC or SystemVerilog. Sometimes special software libraries are used that are aimed at simulation circuits on the system level. The IEEE 1685-2009 standard defines the IP-XACT file format that can be used to represent designs on the system level and building blocks that can be used in such system level designs.

2. Behavioral & Register Transfer Level (VHDL/Verilog)

At the Behavioural Level abstraction a language aimed at hardware description such as Verilog or VHDL is used to describe the circuit, but so-called behavioural modeling is used in at least part of the circuit description. In behavioural modeling there must be a language feature that allows for imperative programming to be used to describe data paths and registers. This is the always -block in Verilog and the process -block in VHDL.

A design in Register Transfer Level representation is usually stored using HDLs like Verilog and VHDL. But only a very limited subset of features is used, namely minimalistic always blocks (Verilog) or process blocks (VHDL) that model the register type used and unconditional assignments for the datapath logic. The use of HDLs on this level simplifies simulation as no additional tools are required to simulate a design in Register Transfer Level representation.

B. BACK-END ENGINEERING

3. Logical Gate

At the Logical Gate Level the design is represented by a netlist that uses only cells from a small number of single-bit cells, such as basic logic gates (AND, OR, NOT, XOR, etc.) and registers (usually D-Type Flip-flops). A number of netlist formats exists that can be used on this level such as the Electronic Design Interchange Format (EDIF), but for ease of simulation often a HDL netlist is used. The latter is a HDL file (Verilog or VHDL) that only uses the most basic language constructs for instantiation and connecting of cells.

4. Physical Gate

On the Physical Gate Level only gates are used that are physically available on the target architecture. In some cases this may only be NAND, NOR and NOT gates as well as D-Type registers. In the case of an FPGA-based design the Physical Gate Level representation is a netlist of LUTs with optional output registers, as these are the basic building blocks of FPGA logic cells.

5. Switch Level

A Switch Level representation of a circuit is a netlist utilizing single transistors as cells. Switch Level modeling is possible in Verilog and VHDL, but is seldom used in modern designs, as in modern digital ASIC or FPGA flows the physical gates are considered the atomic build blocks of the logic circuit.

Settings → Apps → Apps & features → Related settings, Programs and Features → Turn Windows features on or off → Windows Subsystem for Linux
Microsoft Store → INSTALL UBUNTU

Front-End and Back-End Library type:

sudo apt update
sudo apt upgrade

sudo apt install -y bison
sudo apt install -y cmake
sudo apt install -y flex
sudo apt install -y freeglut3-dev
sudo apt install -y libcairo2-dev
sudo apt install -y libgsl-dev
sudo apt install -y libncurses-dev
sudo apt install -y libx11-dev
sudo apt install -y m4
sudo apt install -y python-tk
sudo apt install -y python3-tk
sudo apt install -y swig
sudo apt install -y tcl
sudo apt install -y tcl-dev
sudo apt install -y tk-dev
sudo apt install -y tcsh

Synthesizer Library type:

sudo apt update
sudo apt upgrade

sudo apt install -y build-essential
sudo apt install -y clang
sudo apt install -y bison
sudo apt install -y flex
sudo apt install -y libreadline-dev
sudo apt install -y gawk
sudo apt install -y tcl-dev
sudo apt install -y libffi-dev
sudo apt install -y git
sudo apt install -y make
sudo apt install -y gnat
sudo apt install -y graphviz
sudo apt install -y xdot
sudo apt install -y pkg-config
sudo apt install -y python3
sudo apt install -y libboost-system-dev
sudo apt install -y libboost-python-dev
sudo apt install -y libboost-filesystem-dev
sudo apt install -y zlib1g-dev

FRONT-END OPEN SOURCE TOOLS

Front-End {width=6cm}

Modeling System Level of Hardware

A System Description Language Editor is a computer tool that allows to generate software code. A System Description Language is a formal language, which comprises a Programming Language (input), producing a Hardware Description (output). Programming languages are used in computer programming to implement algorithms. The description of a programming language is split into the two components of syntax (form) and semantics (meaning).

System Description Language Editor

type:

git clone https://github.com/emacs-mirror/emacs

Simulating System Level of Hardware

A System Description Language Simulator (translator) is a computer program that translates computer code written in a Programming Language (the source language) into a Hardware Description Language (the target language). The compiler is primarily used for programs that translate source code from a high-level programming language to a low-level language to create an executable program.

SystemVerilog System Description Language Simulator

type:

git clone http://git.veripool.org/git/verilator

cd verilator
autoconf
./configure
make
sudo make install

cd sim/verilog/regression/wb/verilator
source simulate.sh

cd sim/verilog/regression/ahb3/verilator
source simulate.sh

cd sim/verilog/regression/axi4/verilator
source simulate.sh

Verifying System Level of Hardware

A UVM standard improves interoperability and reduces the cost of repurchasing and rewriting IP for each new project or Electronic Design Automation tool. It also makes it easier to reuse verification components. The UVM Class Library provides generic utilities, such as component hierarchy, Transaction Library Model or configuration database, which enable the user to create virtually any structure wanted for the testbench.

SystemVerilog System Description Language Verifier

type:

git clone https://github.com/QueenField/UVM

Describing Register Transfer Level of Hardware

A Hardware Description Language Editor is any editor that allows to generate hardware code. Hardware Description Language is a specialized computer language used to describe the structure and behavior of digital logic circuits. It allows for the synthesis of a HDL into a netlist, which can then be synthesized, placed and routed to produce the set of masks used to create an integrated circuit.

Hardware Description Language Editor

type:

git clone https://github.com/emacs-mirror/emacs

Simulating Register Transfer Level of Hardware

A Hardware Description Language Simulator uses mathematical models to replicate the behavior of an actual hardware device. Simulation software allows for modeling of circuit operation and is an invaluable analysis tool. Simulating a circuit's behavior before actually building it can greatly improve design efficiency by making faulty designs known as such, and providing insight into the behavior of electronics circuit designs.

VHDL Hardware Description Language Simulator

type:

git clone https://github.com/ghdl/ghdl

cd ghdl
./configure --prefix=/usr/local
make
sudo make install

cd sim/vhdl/regression/wb/ghdl
source simulate.sh

cd sim/vhdl/regression/ahb3/ghdl
source simulate.sh

cd sim/vhdl/regression/axi4/ghdl
source simulate.sh

Verilog Hardware Description Language Simulator

type:

git clone https://github.com/steveicarus/iverilog

cd iverilog
sh autoconf.sh
./configure
make
sudo make install

cd sim/verilog/regression/wb/iverilog
source simulate.sh

cd sim/verilog/regression/ahb3/iverilog
source simulate.sh

cd sim/verilog/regression/axi4/iverilog
source simulate.sh

Synthesizing Register Transfer Level of Hardware

A Hardware Description Language Synthesizer turns a RTL implementation into a Logical Gate Level implementation. Logical design is a step in the standard design cycle in which the functional design of an electronic circuit is converted into the representation which captures logic operations, arithmetic operations, control flow, etc. In EDA parts of the logical design is automated using synthesis tools based on the behavioral description of the circuit.

Verilog Hardware Description Language Synthesizer

type:

git clone https://github.com/YosysHQ/yosys

cd yosys
make
sudo make install

cd synthesis/yosys
source synthesize.sh

VHDL Hardware Description Language Synthesizer

type for Plugin:

git clone https://github.com/ghdl/ghdl-yosys-plugin

cd ghdl-yosys-plugin
make GHDL=/usr/local
sudo yosys-config --exec mkdir -p --datdir/plugins
sudo yosys-config --exec cp "ghdl.so" --datdir/plugins/ghdl.so

cd synthesis/yosys
source synthesize.sh

Optimizing Register Transfer Level of Hardware

A Hardware Description Language Optimizer finds an equivalent representation of the specified logic circuit under specified constraints (minimum area, pre-specified delay). This tool combines scalable logic optimization based on And-Inverter Graphs (AIGs), optimal-delay DAG-based technology mapping for look-up tables and standard cells, and innovative algorithms for sequential synthesis and verification.

Verilog Hardware Description Language Optimizer

type:

git clone https://github.com/YosysHQ/yosys

cd yosys
make
sudo make install

cd synthesis/yosys
source synthesize.sh

Verifying Register Transfer Level of Hardware

A Hardware Description Language Verifier proves or disproves the correctness of intended algorithms underlying a hardware system with respect to a certain formal specification or property, using formal methods of mathematics. Formal verification uses modern techniques (SAT/SMT solvers, BDDs, etc.) to prove correctness by essentially doing an exhaustive search through the entire possible input space (formal proof).

Verilog Hardware Description Language Verifier

type:

git clone https://github.com/YosysHQ/SymbiYosys

BACK-END OPEN SOURCE TOOLS

Back-End {width=6cm}

Library

type:

sudo apt update
sudo apt upgrade

sudo apt install -y bison
sudo apt install -y cmake
sudo apt install -y flex
sudo apt install -y freeglut3-dev
sudo apt install -y libcairo2-dev
sudo apt install -y libgsl-dev
sudo apt install -y libncurses-dev
sudo apt install -y libx11-dev
sudo apt install -y m4
sudo apt install -y python-tk
sudo apt install -y python3-tk
sudo apt install -y swig
sudo apt install -y tcl
sudo apt install -y tcl-dev
sudo apt install -y tk-dev
sudo apt install -y tcsh

Back-End Workflow Qflow

type:

git clone https://github.com/RTimothyEdwards/qflow

cd qflow
./configure
make
sudo make install

mkdir qflow
cd qflow

Planning Switch Level of Hardware

A Floor-Planner of an Integrated Circuit (IC) is a schematic representation of tentative placement of its major functional blocks. In modern electronic design process floor-plans are created during the floor-planning design stage, an early stage in the hierarchical approach to Integrated Circuit design. Depending on the design methodology being followed, the actual definition of a floor-plan may differ.

Floor-Planner

type:

git clone https://github.com/RTimothyEdwards/magic

cd magic
./configure
make
sudo make install

Placing Switch Level of Hardware

A Standard Cell Placer takes a given synthesized circuit netlist together with a technology library and produces a valid placement layout. The layout is optimized according to the aforementioned objectives and ready for cell resizing and buffering, a step essential for timing and signal integrity satisfaction. Physical design flow are iterated a number of times until design closure is achieved.

Standard Cell Placer

type:

git clone https://github.com/rubund/graywolf

cd graywolf
mkdir build
cd build
cmake ..
make
sudo make install

Timing Switch Level of Hardware

A Standard Cell Timing-Analizer is a simulation method of computing the expected timing of a digital circuit without requiring a simulation of the full circuit. High-performance integrated circuits have traditionally been characterized by the clock frequency at which they operate. Measuring the ability of a circuit to operate at the specified speed requires an ability to measure, during the design process, its delay at numerous steps.

Standard Cell Timing-Analizer

type:

git clone https://github.com/The-OpenROAD-Project/OpenSTA

cd OpenSTA
mkdir build
cd build
cmake ..
make
sudo make install

Routing Switch Level of Hardware

A Standard Cell Router takes pre-existing polygons consisting of pins on cells, and pre-existing wiring called pre-routes. Each of these polygons are associated with a net. The primary task of the router is to create geometries such that all terminals assigned to the same net are connected, no terminals assigned to different nets are connected, and all design rules are obeyed.

Standard Cell Router

type:

git clone https://github.com/RTimothyEdwards/qrouter

cd qrouter
./configure
make
sudo make install

Simulating Switch Level of Hardware

A Standard Cell Simulator treats transistors as ideal switches. Extracted capacitance and lumped resistance values are used to make the switch a little bit more realistic than the ideal, using the RC time constants to predict the relative timing of events. This simulator represents a circuit in terms of its exact transistor structure but describes the electrical behavior in a highly idealized way.

Standard Cell Simulator

type:

git clone https://github.com/RTimothyEdwards/irsim

cd irsim
./configure
make
sudo make install

Verifying Switch Level of Hardware LVS

A Standard Cell Verifier compares netlists, a process known as LVS (Layout vs. Schematic). This step ensures that the geometry that has been laid out matches the expected circuit. The greatest need for LVS is in large analog or mixed-signal circuits that cannot be simulated in reasonable time. LVS can be done faster than simulation, and provides feedback that makes it easier to find errors.

Standard Cell Verifier

type:

git clone https://github.com/RTimothyEdwards/netgen

cd netgen
./configure
make
sudo make install

cd synthesis/qflow
source flow.sh

Checking Switch Level of Hardware DRC

A Standard Cell Checker is a geometric constraint imposed on Printed Circuit Board (PCB) and Integrated Circuit (IC) designers to ensure their designs function properly, reliably, and can be produced with acceptable yield. Design Rules for production are developed by hardware engineers based on the capability of their processes to realize design intent. Design Rule Checking (DRC) is used to ensure that designers do not violate design rules.

Standard Cell Checker

type:

git clone https://github.com/RTimothyEdwards/magic

cd magic
./configure
make
sudo make install

Printing Switch Level of Hardware GDS

A Standard Cell Editor allows to print a set of standard cells. The standard cell methodology is an abstraction, whereby a low-level VLSI layout is encapsulated into a logical representation. A standard cell is a group of transistor and interconnect structures that provides a boolean logic function (AND, OR, XOR, XNOR, inverters) or a storage function (flipflop or latch).

Standard Cell Editor

type:

git clone https://github.com/RTimothyEdwards/magic

cd magic
./configure
make
sudo make install