derek/splitncover-paper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
Derek Christ
2024-06-21 09:01:23 +00:00
committed by node
parent 6c6bcf0319
commit fa768c2305
11 changed files with 626 additions and 80275 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
blocks-safety-methodology.tex
View File

@@ -22,18 +22,20 @@
\end{tikzpicture}% \end{tikzpicture}%
} }
\subcaptionbox{Coverage}{% \subcaptionbox{\newer{Coverage}}{%
\begin{tikzpicture} \begin{tikzpicture}
\draw (0,0) rectangle ++(3,2); \draw (0,0) rectangle ++(3,2);
\draw (1.5,0.5) node(){\textbf{Coverage}}; \draw (1.5,0.5) node(){\textbf{Coverage}};
\draw (0,1) -- ++(3,0); \draw (0,1) -- ++(3,0);
\draw (1.5,1.5) node(){$c$}; \draw (0.75,1.5) node(){\newer{$c_{R}$}};
\draw (1.5,1.0) -- ++(0,1);
\draw (2.25,1.5) node(){\newer{$c_{L}$}};
\draw (1.375,-0.25) rectangle ++(0.25,0.25); \draw (1.375,-0.25) rectangle ++(0.25,0.25);
\draw (1.5,-0.5) node(){$\lambda_\mathrm{in}$}; \draw (1.5,-0.5) node(){$\lambda_\mathrm{in}$};
\draw[fill=black] (0.75,2.0) rectangle ++(0.25,0.25); \draw[fill=black] (0.625,2.0) rectangle ++(0.25,0.25);
\draw (0.875,2.5) node(){$\lambda_\mathrm{RF}$}; \draw (0.75,2.5) node(){$\lambda_\mathrm{RF}$};
\draw[fill=black] (2.0,2.0) rectangle ++(0.25,0.25); \draw[fill=black] (2.125,2.0) rectangle ++(0.25,0.25);
\draw (2.125,2.5) node(){$\lambda_\mathrm{MPF,L}$}; \draw (2.25,2.5) node(){$\lambda_\mathrm{MPF,L}$};
\end{tikzpicture}% \end{tikzpicture}%
}\quad\quad\quad }\quad\quad\quad
\subcaptionbox{Split}{% \subcaptionbox{Split}{%

369
blocks.tex Normal file
View File

@@ -0,0 +1,369 @@
\usetikzlibrary{shapes.multipart}
\usetikzlibrary {shapes.geometric}
\tikzset{inport/.style={
draw=black, minimum width=0.1cm, minimum height=0.1cm, anchor=north, outer sep=0, inner sep=2.75
}}
\tikzset{outport/.style={
draw=black, fill=black, minimum width=0.1cm, minimum height=0.1cm, anchor=south, outer sep=0, inner sep=2.75
}}
\makeatletter
\pgfdeclareshape{coverage}{
% Minimum required anchors:
\savedanchor{\northeast}{
\pgf@y=1cm
\pgf@x=1.5cm
}
\savedanchor{\southwest}{
\pgf@y=-\pgf@y
\pgf@x=-\pgf@x
}
% Special Anchors, that can be calculated from the others (lazy calculation)
\anchor{south west} {\southwest}
\anchor{north east} {\northeast}
\anchor{north west} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{south east} {\southwest \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{west} {\southwest \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{east} {\northeast \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{north} {\northeast \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{south} {\southwest \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{center} {\pgfpointorigin}
\anchor{out 2} {\northeast \pgfpoint{0.5\pgf@x}{\pgf@y+0.2cm}}
\anchor{out 1} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x \pgfpoint{0.5\pgf@x}{\pgf@y+0.2cm}}
\anchor{in} {\southwest \pgf@y=\pgf@y \pgf@x=0cm \pgfpoint{0.5\pgf@x}{\pgf@y-0.2cm}}
\anchor{text} {\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox+0.5cm}}
\backgroundpath{
\pgfsetstrokecolor{black}
\pgfsetfillcolor{black}
\pgfsetarrowsstart{}
\pgfsetarrowsend{}
% Construct main path
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
% construct middle line:
\southwest \pgf@ya=0cm \pgf@xa=\pgf@x
\northeast \pgf@yb=0cm \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
\pgfusepath{stroke}
% Coverage lable:
\southwest \pgf@ya=0.5\pgf@y \pgf@xa=0cm
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\bf Coverage}
\pgfusepath{stroke}
% Construct Output1:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.5\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=0.5\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Output2:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.5\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Input1:
\southwest \pgf@ya=\pgf@y \pgf@xa=0cm
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
}
}
%%%%%%%%%%%%%%%%%%%%%%
\pgfkeys{/tikz/split1 top/.initial = 50\%}
\pgfdeclareshape{split1}{%
% Minimum required anchors:
\savedanchor{\northeast}{
\pgf@y=1cm
\pgf@x=0.75cm
}
\savedanchor{\southwest}{
\pgf@y=-\pgf@y
\pgf@x=-\pgf@x
}
% Special Anchors, that can be calculated from the others (lazy calculation)
\anchor{south west} {\southwest}
\anchor{north east} {\northeast}
\anchor{north west} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{south east} {\southwest \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{west} {\southwest \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{east} {\northeast \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{north} {\northeast \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{south} {\southwest \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{center} {\pgfpointorigin}
\anchor{out 1} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x \pgfpoint{0.0\pgf@x}{\pgf@y+0.2cm}}
\anchor{in} {\southwest \pgf@y=\pgf@y \pgf@x=0cm \pgfpoint{0.5\pgf@x}{\pgf@y-0.2cm}}
\anchor{text} {\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox+0.5cm}}
\backgroundpath{
\pgfsetfillcolor{black}
\pgfsetstrokecolor{black}
\pgfsetarrowsstart{}
\pgfsetarrowsend{}
% Construct main path
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
% Construct middle line:
\southwest \pgf@ya=0cm \pgf@xa=\pgf@x
\northeast \pgf@yb=0cm \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
% Coverage lable:
\southwest \pgf@ya=0.5\pgf@y \pgf@xa=0cm
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\bf Split}
\pgfusepath{stroke}
% Left lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=0cm
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split1 top}}
\pgfusepath{stroke}
% Construct Output1:
\northeast \pgf@ya=\pgf@y \pgf@xa=1.0\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=0.0\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Input1:
\southwest \pgf@ya=\pgf@y \pgf@xa=0cm
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
}
}
\pgfkeys{/tikz/split2 left/.initial = 50\%}
\pgfkeys{/tikz/split2 right/.initial = 50\%}
\pgfdeclareshape{split2}{%
% Minimum required anchors:
\savedanchor{\northeast}{
\pgf@y=1cm
\pgf@x=1.5cm
}
\savedanchor{\southwest}{
\pgf@y=-\pgf@y
\pgf@x=-\pgf@x
}
% Special Anchors, that can be calculated from the others (lazy calculation)
\anchor{south west} {\southwest}
\anchor{north east} {\northeast}
\anchor{north west} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{south east} {\southwest \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{west} {\southwest \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{east} {\northeast \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{north} {\northeast \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{south} {\southwest \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{center} {\pgfpointorigin}
\anchor{out 2} {\northeast \pgfpoint{0.5\pgf@x}{\pgf@y+0.2cm}}
\anchor{out 1} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x \pgfpoint{0.5\pgf@x}{\pgf@y+0.2cm}}
\anchor{in} {\southwest \pgf@y=\pgf@y \pgf@x=0cm \pgfpoint{0.5\pgf@x}{\pgf@y-0.2cm}}
\anchor{text} {\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox+0.5cm}}
\backgroundpath{
\pgfsetfillcolor{black}
\pgfsetstrokecolor{black}
\pgfsetarrowsstart{}
\pgfsetarrowsend{}
% Construct main path
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
% Construct middle line:
\southwest \pgf@ya=0cm \pgf@xa=\pgf@x
\northeast \pgf@yb=0cm \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
% Vertical Middle Line:
\northeast \pgf@yb=\pgf@y \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{0cm}{0cm}}
\pgfpathlineto{\pgfpoint{0cm}{\pgf@yb}}
\pgfusepath{stroke}
% Coverage lable:
\southwest \pgf@ya=0.5\pgf@y \pgf@xa=0cm
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\bf Split}
\pgfusepath{stroke}
% Left lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=-0.5\pgf@x
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split2 left}}
\pgfusepath{stroke}
% Right lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=0.5\pgf@x
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split2 right}}
\pgfusepath{stroke}
% Construct Output1:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.5\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=0.5\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Output2:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.5\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Input1:
\southwest \pgf@ya=\pgf@y \pgf@xa=0cm
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
}
}
\pgfkeys{/tikz/split3 left/.initial = 50\%}
\pgfkeys{/tikz/split3 middle/.initial = 50\%}
\pgfkeys{/tikz/split3 right/.initial = 50\%}
\pgfdeclareshape{split3}{%
% Minimum required anchors:
\savedanchor{\northeast}{
\pgf@y=1cm
\pgf@x=1.5cm
}
\savedanchor{\southwest}{
\pgf@y=-\pgf@y
\pgf@x=-\pgf@x
}
% Special Anchors, that can be calculated from the others (lazy calculation)
\anchor{south west} {\southwest}
\anchor{north east} {\northeast}
\anchor{north west} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{south east} {\southwest \pgf@y=\pgf@y \pgf@x=-\pgf@x}
\anchor{west} {\southwest \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{east} {\northeast \pgf@y=0cm \pgf@x=\pgf@x}
\anchor{north} {\northeast \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{south} {\southwest \pgf@y=\pgf@y \pgf@x=0cm}
\anchor{center} {\pgfpointorigin}
\anchor{out 1} {\northeast \pgf@y=\pgf@y \pgf@x=-\pgf@x \pgfpoint{0.666\pgf@x}{\pgf@y+0.2cm}}
\anchor{out 2} {\northeast \pgfpoint{0.0\pgf@x}{\pgf@y+0.2cm}}
\anchor{out 3} {\northeast \pgfpoint{0.666\pgf@x}{\pgf@y+0.2cm}}
\anchor{in} {\southwest \pgf@y=\pgf@y \pgf@x=0cm \pgfpoint{0.5\pgf@x}{\pgf@y-0.2cm}}
\anchor{text} {\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox+0.5cm}}
\backgroundpath{
\pgfsetfillcolor{black}
\pgfsetstrokecolor{black}
\pgfsetarrowsstart{}
\pgfsetarrowsend{}
% Construct main path
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
% Construct middle line:
\southwest \pgf@ya=0cm \pgf@xa=\pgf@x
\northeast \pgf@yb=0cm \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yb}}
% Vertical Middle Lines:
\southwest \pgf@ya=0cm \pgf@xa=\pgf@x
\northeast \pgf@yb=\pgf@y \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa+1cm}{0cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa+1cm}{\pgf@yb}}
\pgfusepath{stroke}
%
\northeast \pgf@ya=\pgf@y \pgf@xa=\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa-1cm}{0cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-1cm}{\pgf@ya}}
\pgfusepath{stroke}
% Coverage lable:
\southwest \pgf@ya=0.5\pgf@y \pgf@xa=0cm
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\bf Split}
\pgfusepath{stroke}
% Left lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=-0.666\pgf@x
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split3 left}}
\pgfusepath{stroke}
% Middle lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=0.000\pgf@x
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split3 middle}}
\pgfusepath{stroke}
% Right lable:
\northeast \pgf@ya=0.5\pgf@y \pgf@xa=0.666\pgf@x
\pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\pgfkeysvalueof{/tikz/split3 right}}
\pgfusepath{stroke}
% Construct Output1:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.666\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=0.666\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Output2:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.0\pgf@x
\southwest \pgf@yb=\pgf@y \pgf@xb=0.0\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xb+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xb-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Output3:
\northeast \pgf@ya=\pgf@y \pgf@xa=0.666\pgf@x
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya+0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke, fill}
% Construct Input1:
\southwest \pgf@ya=\pgf@y \pgf@xa=0cm
\pgfpathmoveto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya}}
\pgfpathlineto{\pgfpoint{\pgf@xa+0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya-0.2cm}}
\pgfpathlineto{\pgfpoint{\pgf@xa-0.1cm}{\pgf@ya}}
\pgfpathclose
\pgfusepath{stroke}
}
}
\makeatother

84
ecc_results.tex
View File

@@ -1,84 +0,0 @@
\begin{figure}[p]
\centering
\begin{tikzpicture}
\begin{axis}[
width=0.85*\textwidth,
x tick label style={/pgf/number format/1000 sep=},
xlabel={Latency [ns]},
ylabel=Occurences,
xmin=0, xmax=450,
ymin=1, ymax=20000,
%enlargelimits=0.05,
ymode=log,
]
\addplot[hist={bins=150}]
table[col sep=comma, header=true, y index=0]{seq_without_ECC.csv};
\end{axis}
\end{tikzpicture}
\caption{Sequential without ECC}
\label{fig:linear-wo-ecc}
\end{figure}
\begin{figure}[p]
\centering
\begin{tikzpicture}
\begin{axis}[
width=0.85*\textwidth,
x tick label style={/pgf/number format/1000 sep=},
xlabel={Latency [ns]},
ylabel=Occurences,
xmin=0, xmax=450,
ymin=1, ymax=20000,
%enlargelimits=0.05,
ymode=log,
]
\addplot[hist={bins=150}]
table[col sep=comma, header=true, y index=0]{seq_with_ECC.csv};
\end{axis}
\end{tikzpicture}
\caption{Sequential with ECC}
\label{fig:linear-w-ecc}
\end{figure}
\begin{figure}[p]
\centering
\begin{tikzpicture}
\begin{axis}[
width=0.85*\textwidth,
x tick label style={/pgf/number format/1000 sep=},
xlabel={Latency [ns]},
ylabel=Occurences,
xmin=0, xmax=1200,
ymin=1, ymax=20000,
%enlargelimits=0.05,
ymode=log,
]
\addplot[hist={bins=150}]
table[col sep=comma, header=true, y index=0]{random_without_ECC.csv};
%\legend{Random without ECC}
\end{axis}
\end{tikzpicture}
\caption{Random without ECC}
\label{fig:rand-wo-ecc}
\end{figure}
\begin{figure}[p]
\centering
\begin{tikzpicture}
\begin{axis}[
width=0.85*\textwidth,
x tick label style={/pgf/number format/1000 sep=},
xlabel={Latency [ns]},
ylabel=Occurences,
xmin=0, xmax=1200,
ymin=1, ymax=20000,
%enlargelimits=0.05,
ymode=log,
]
\addplot[hist={bins=150}]
table[col sep=comma, header=true, y index=0]{random_with_ECC.csv};
\end{axis}
\end{tikzpicture}
\caption{Random with ECC}
\label{fig:rand-w-ecc}
\end{figure}

203
main.tex
View File

@@ -74,6 +74,7 @@
\usepackage{circuitikz} \usepackage{circuitikz}
\usetikzlibrary{fit} \usetikzlibrary{fit}
\usetikzlibrary{calc} \usetikzlibrary{calc}
\input{blocks}
\lstset{ \lstset{
literate={~} {$\sim$}{1} literate={~} {$\sim$}{1}
@@ -117,7 +118,7 @@ thank you for the valuable reviews of our journal paper. We revised the paper ac
\reviewer{Section (6) presents the safety and performance analysis. The results are exactly the same as those presented in the previous publication for LPDDR4. As mentioned by the authors, LPDDR5 introduces the Link ECC; Therefore, a more exhaustive explanation of the reason of non-improvement is desired. Please extend (if possible) this part of the paper.} \reviewer{Section (6) presents the safety and performance analysis. The results are exactly the same as those presented in the previous publication for LPDDR4. As mentioned by the authors, LPDDR5 introduces the Link ECC; Therefore, a more exhaustive explanation of the reason of non-improvement is desired. Please extend (if possible) this part of the paper.}
\answer{We thank the reviewer for their suggestion of a more detailed explanation of the differences between the earlier LPDDR4 analysis and the extended LPDDR5 analysis. We agree that the minor differences in the results following from introducing the additional Link-ECC should be explained in more detail \todo{and have updated Section (7) Experimental Results to reflect this.}} \answer{We thank the reviewer for their suggestion of a more detailed explanation of the differences between the earlier LPDDR4 analysis and the extended LPDDR5 analysis. We agree that the minor differences in the results following from introducing the additional Link-ECC should be explained in more detail and have updated Section (7) Experimental Results to reflect this.}
\reviewer{Section "1" (Introduction) is missing after the abstract.} \reviewer{Section "1" (Introduction) is missing after the abstract.}
@@ -153,7 +154,10 @@ thank you for the valuable reviews of our journal paper. We revised the paper ac
- The author should probably consider describing a larger proposal to evaluate the impact of possible safety measures since the beginning of the paper. - The author should probably consider describing a larger proposal to evaluate the impact of possible safety measures since the beginning of the paper.
} }
\answer{We agree with the statement that the main methodology of the SystemC-based and ISO26262-compliant safety analysis first presented in the SAMOS paper is largely the same and would like to thank the reviewer for highlighting this. The additional contribution focuses on the new considerations regarding LPDDR5, such as the new link ECC mechanism added due to the increased interface failure rate. As correctly noted, the new performance analysis conducted is essentially orthogonal to the previous analysis and examines the bandwidth and latency impact of an additional in-line ECC mechanism. This analysis was motivated based on the results that suggested that additional safety mechanisms are needed to achieve a high level of ASIL compliance. We agree that the introduction should include the intent of the paper to analyze a further and larger proposal for safety analysis compared to the earlier SAMOS paper, and have incorporated this accordingly. The focus of the paper should now be clearer to the reader from the beginning on.} \answer{We agree with the statement that the main methodology of the SystemC-based and ISO26262-compliant safety analysis first presented in the SAMOS paper is largely the same and would like to thank the reviewer for highlighting this. The additional contribution focuses on the new considerations regarding LPDDR5, such as the new link ECC mechanism added due to the increased interface failure rate as well as the usage of an inline ECC instead of the previous side-band ECC.
As correctly noted, the new performance analysis is essentially orthogonal to the safety analysis.
However, it examines the bandwidth and latency impact of the very same inline ECC mechanism considered in the safety analysis.
We agree that the introduction should include the intent of the paper to analyze a further and larger proposal for safety analysis compared to the earlier SAMOS paper, and have incorporated this accordingly. The focus of the paper should now be clearer to the reader from the beginning on.}
\subsection*{Reviewer 3} \subsection*{Reviewer 3}
\reviewer{% \reviewer{%
@@ -183,16 +187,16 @@ It seems recommendable that the authors either rethink their approach of a rate-
\answer{% \answer{%
We thank the reviewer for their thorough analysis of the mathematical soundness of our proposed model. We thank the reviewer for their thorough analysis of the mathematical soundness of our proposed model.
We fully agree that from a strict mathematical standpoint, the constant fault rates are only an approximation and that the mixing of constant probabilities with those rates in turn do not result in constant rates. We fully agree that from a strict mathematical standpoint, the constant failure rates are only an approximation and that the mixing of constant probabilities with those rates in turn do not result in constant rates.
However, as our approach is oriented towards the metrics and analysis performed in the ISO26262. However, as our approach is oriented towards the metrics and analysis performed in the ISO26262.
Not only assume we a constant failure rate as denoted in the Section \ref{sec:background} refering to the constant region of the bathtub curve, but we also we leverage the calculation principles of the ISO. Not only assume we a constant failure rate as denoted in the Section \ref{sec:background} refering to the constant region of the bathtub curve, but we also we leverage the calculation principles of the ISO.
For example, in our approach we calculate the residual fault rates of a coverage block by multiplying a probability with the input fault rate. For example, in our approach we calculate the residual failure rates of a coverage block by multiplying a probability with the input failure rate.
This is in line with the calculation as done by Formula C.3 in ISO26262-5: This is in line with the calculation as done by Formula C.3 in ISO26262-5:
$$\lambda_{RF} \leq \lambda_{RF,est} = \lambda \cdot \left(1-\frac{K_{DC,RF}}{100\%}\right)$$ $$\lambda_{RF} \leq \lambda_{RF,est} = \lambda \cdot \left(1-\frac{K_{DC,RF}}{100\%}\right)$$
Similarly, the latent multi point fault rate of our coverage block is calculated in accordance to Formula C.5: Similarly, the latent multi point failure rate of our coverage block is calculated in accordance to Formula C.5:
$$\lambda_{MPF,L} \leq \lambda_{MPF,L,est} = \lambda \cdot \left(1-\frac{K_{DC,MPF,L}}{100\%}\right)$$ $$\lambda_{MPF,L} \leq \lambda_{MPF,L,est} = \lambda \cdot \left(1-\frac{K_{DC,MPF,L}}{100\%}\right)$$
Consequently, our approximations are in line with the simplifications that are done by the ISO, which itself refers to these formulas as conservative approximations. Consequently, our approximations are in line with the simplifications that are done by the ISO, which itself refers to these formulas as conservative approximations.
\todo{To better convey these approximations to the reader, we have now described this aspect in more detail in Section \ref{}}. To better convey these approximations to the reader, we have now described this aspect in more detail in Section \ref{sec:background}.
Further, we fully agree with the reviewer that the error correction and detection capabilities of coverage mechanisms only denote the theoretical maximum, since they themselves could be a failing hardware component. Further, we fully agree with the reviewer that the error correction and detection capabilities of coverage mechanisms only denote the theoretical maximum, since they themselves could be a failing hardware component.
In our approach we modeled this circumstance by introducing additional basic events that contribute to the total latent multi-point fault metric, as these are faults that become visible in combination with another independent fault. In our approach we modeled this circumstance by introducing additional basic events that contribute to the total latent multi-point fault metric, as these are faults that become visible in combination with another independent fault.
@@ -205,7 +209,7 @@ In terms of evaluation, it would be good to see a comparison of their approach w
} }
\answer{We thank the reviewer for their suggestion to further analyze the impact of common fault causes such as heat that affects multiple components at once. \answer{We thank the reviewer for their suggestion to further analyze the impact of common fault causes such as heat that affects multiple components at once.
Indeed, such common causes would result in the fault rates no longer being independent and would require a more thorough analysis. Indeed, such common causes would result in the failure rates no longer being independent and would require a more thorough analysis.
However, we concentrate on our analysis on a safety element out of context: However, we concentrate on our analysis on a safety element out of context:
The integration of the memory system into the complete vehicle would go beyond the scope of this paper. The integration of the memory system into the complete vehicle would go beyond the scope of this paper.
Further, we agree that a more extensive sensitivity analysis regarding input variances would be a worthwhile effort that could be subject to further work. Further, we agree that a more extensive sensitivity analysis regarding input variances would be a worthwhile effort that could be subject to further work.
@@ -222,7 +226,7 @@ Overall, however, the approach as such is appealing and the aspects mentioned ab
} }
\answer{We would like express our appreciation to reviewer for recognizing the appeal of our novel approach and the confidence in its potential. \answer{We would like express our appreciation to reviewer for recognizing the appeal of our novel approach and the confidence in its potential.
We also agree with the observation that the approximations involved should be more clearly described in the text, \todo{and have therefore overworked such clarifications so that our approach relies extensively on the estimates made in ISO26262.}} We also agree with the observation that the approximations involved should be more clearly described in the text, and have therefore overworked such clarifications so that our approach relies extensively on the estimates made in ISO26262.}
\newpage \newpage
@@ -340,12 +344,12 @@ In this section, we present the basic requirements on safety in order to underst
For the safety analysis of hardware, we follow the definitions of Laprie et\,al.~\cite{avilap_04}: For the safety analysis of hardware, we follow the definitions of Laprie et\,al.~\cite{avilap_04}:
\begin{description} \begin{description}
\item[Fault:] Is a defect within the system and the root cause of the violation of a safety goal, e.g., a stuck-at 0 or single event upset due to a cosmic ray. \item[Fault] is a defect within the system and the root cause of the violation of a safety goal, e.g., a stuck-at 0 or single event upset due to a cosmic ray.
\item[Error:] Is an erroneous internal state, e.\,g., in the memory or the CPU, where the fault becomes visible. \item[Error] is an erroneous internal state, e.\,g., in the memory or the CPU, where the fault becomes visible.
\item[Failure:] Is when the error is observed and the system's behavior deviates from the specification. This might lead to the violation of a safety goal. \item[Failure] is when the error is observed and the behavior of the system deviates from the specification. This might lead to the violation of a safety goal.
\end{description} \end{description}
As shown in Figure~\ref{fig:bathtube}, hardware failure rates $\lambda(t)$ usually follow the so-called \textit{Bathtub Curve}. In phase \textbf{I}, we can observe early failures called \textit{Infant Mortality}. In phase \textbf{II}, there exists a constant failure rate, known as random failures. This phase is also called \textit{Useful Lifetime}. Therefore, a burn-in process of the product is used to artificially age the product, such that the product enters the marked in phase II. The third phase \textbf{III} shows the \textit{Wear-Out} of the product, where the failure rate increases due to wear-out, i.\,e., aging effects. As shown in Figure~\ref{fig:bathtube}, hardware failure rates $\lambda(t)$ usually follow the so-called \textit{Bathtub Curve}. In Phase \textbf{I}, we can observe early failures called \textit{Infant Mortality}. In Phase \textbf{II}, there exists a constant failure rate, known as random failures. This phase is also called \textit{Useful Lifetime}. Therefore, a burn-in process of the product is used to artificially age the product, such that the product enters the marked in Phase II. Phase \textbf{III} shows the \textit{Wear-Out} of the product, where the failure rate increases due to wear-out, i.\,e., aging effects.
% %
\begin{figure} \begin{figure}
\centering \centering
@@ -372,6 +376,13 @@ The constant failure rate of this distribution $\lambda$ is measured in \textit{
$$\lambda = \lambda_\mathrm{SPF} + \lambda_\mathrm{RF} + \lambda_\mathrm{MPF} + \lambda_\mathrm{S}$$ $$\lambda = \lambda_\mathrm{SPF} + \lambda_\mathrm{RF} + \lambda_\mathrm{MPF} + \lambda_\mathrm{S}$$
% %
\newer{%
In order to calculate $\lambda_{RF}$ of a safety mechanism, the ISO\,26262 defines a conservative approximation using a diagnostic coverage value $K_{DC}$ as in Formula C.3 of the Section ISO\,26262-5:
$$\lambda_{RF} \leq \lambda_{RF,est} = \lambda \cdot \left(1-\frac{K_{DC,RF}}{100\%}\right)$$
Similarly, the approximate value of $\lambda_{MPF,L}$ is calculated as in Formula C.5:
$$\lambda_{MPF,L} \leq \lambda_{MPF,L,est} = \lambda \cdot \left(1-\frac{K_{DC,MPF,L}}{100\%}\right)$$
}
The ISO\,26262 furthermore specifies the hardware metrics used to evaluate the risk posed by hardware elements: The ISO\,26262 furthermore specifies the hardware metrics used to evaluate the risk posed by hardware elements:
\begin{description} \begin{description}
\item[Single-Point Fault Metric (SPFM):] This metric reflects the coverage of a hardware element with respect to single-point faults either by design or by coverage via safety mechanisms. \item[Single-Point Fault Metric (SPFM):] This metric reflects the coverage of a hardware element with respect to single-point faults either by design or by coverage via safety mechanisms.
@@ -401,10 +412,10 @@ Table \ref{tab:target} shows the required target values for $\lambda_\mathrm{RF}
\section{Related Work} \section{Related Work}
\label{sec:related} \label{sec:related}
% %
This section discusses related work and the state of the art.\todo{new or newer?} This section discusses related work and the state of the art.
\new{Today's safety standards, such as ISO\,26262, recommend techniques such as \textit{Failure Mode and Effects Analysis} (FMEA), Fault Tree Analysis (FTA) or Markov Chains for safety analysis. However, none of these techniques can be used directly to obtain the hardware metrics (SPFM and LFM). FMEA as an inductive analysis technique, is suitable for investigating the system from the bottom up and identifying root causes that lead to unwanted system effects. This is helpful in understanding the relationship between HW faults and safety goal violations at the system level. However, FMEA is a purely qualitative analysis technique and therefore not suitable for calculating the desired HW metrics. In practice, a \textit{Failure Mode Effects and Diagnostic Analysis} (FMEDA) is used instead. FMEDAs are typically performed using spreadsheets to systematically examine the HW of the system under analysis for root causes. For each root cause that has the potential to violate a safety goal, safety mechanisms are identified and the coverage with respect to residual and latent faults is determined, providing the basis for calculating the HW metrics for the system under consideration. A special aspect of this technique is that each HW element is analyzed atomically. This is an advantage from a modularization point of view but can be seen as a disadvantage in understanding complex functional dependencies between these elements. In this respect other techniques may be more appropriate.} \newer{Today's safety standards, such as ISO\,26262, recommend techniques such as \textit{Failure Mode and Effects Analysis} (FMEA), Fault Tree Analysis (FTA) or Markov Chains for safety analysis. However, none of these techniques can be used directly to obtain the hardware metrics (SPFM and LFM). FMEA as an inductive analysis technique, is suitable for investigating the system from the bottom up and identifying root causes that lead to unwanted system effects. This is helpful in understanding the relationship between HW faults and safety goal violations at the system level. However, FMEA is a purely qualitative analysis technique and therefore not suitable for calculating the desired HW metrics. In practice, a \textit{Failure Mode Effects and Diagnostic Analysis} (FMEDA) is used instead. FMEDAs are typically performed using spreadsheets to systematically examine the HW of the system under analysis for root causes. For each root cause that has the potential to violate a safety goal, safety mechanisms are identified and the coverage with respect to residual and latent faults is determined, providing the basis for calculating the HW metrics for the system under consideration. A special aspect of this technique is that each HW element is analyzed atomically. This is an advantage from a modularization point of view but can be seen as a disadvantage in understanding complex functional dependencies between these elements. In this respect other techniques may be more appropriate.}
\new{Analysis techniques, such as Markov Chains and Fault Trees, are more expressive and better suited to qualitatively and quantitatively examine complex dependencies. In practice, however, they are less favored, in part because they are typically required only when high assurance levels are required and in part because they can be more demanding from a modeling perspective. The latter is in particularly true for Markov Chains, as the models can grow very rapidly, leading to models that are difficult to understand and maintain. Fault Trees and in particular Component Fault Trees (CFT) introduced by \newer{Kaiser et\,al.~\cite{kailig_03}} offer a more structured approach. They have the ability to modularize and associate Fault Trees with each of the elements in the HW. Consequently, CFT models compose fault trees according to the hierarchical structure employed in the system design. From the point of view of computing HW metrics, as mentioned earlier, these techniques do not allow a direct computation, since they allow at most the calculation of the probability of occurrence of events. Theoretically, it would be possible to integrate new modeling elements, such as a "measure" type of event to integrate the computation of the coverage fraction of the safety mechanisms. However, this is likely to increase the modeling effort and the complexity of the models. \newer{Analysis techniques, such as Markov Chains and Fault Trees, are more expressive and better suited to qualitatively and quantitatively examine complex dependencies. In practice, however, they are less favored, in part because they are typically required only when high assurance levels are required and in part because they can be more demanding from a modeling perspective. The latter is in particularly true for Markov Chains, as the models can grow very rapidly, leading to models that are difficult to understand and maintain. Fault Trees and in particular Component Fault Trees (CFT) introduced by Kaiser et\,al.~\cite{kailig_03} offer a more structured approach. They have the ability to modularize and associate Fault Trees with each of the elements in the HW. Consequently, CFT models compose fault trees according to the hierarchical structure employed in the system design. From the point of view of computing HW metrics, as mentioned earlier, these techniques do not allow a direct computation, since they allow at most the calculation of the probability of occurrence of events. Theoretically, it would be possible to integrate new modeling elements, such as a "measure" type of event to integrate the computation of the coverage fraction of the safety mechanisms. However, this is likely to increase the modeling effort and the complexity of the models.
Our method combines the most important aspects of the above techniques. First, we overcome the drawback of FMEDA by defining a graphical notation capable of maintaining the level of expressiveness similar to CFTs, while keeping the modeling approach simple, allowing us to investigate complex dependencies between the HW elements. Second, we maintain the simplified computation of the HW metrics of FMEDA by integrating dedicated modeling elements.} Our method combines the most important aspects of the above techniques. First, we overcome the drawback of FMEDA by defining a graphical notation capable of maintaining the level of expressiveness similar to CFTs, while keeping the modeling approach simple, allowing us to investigate complex dependencies between the HW elements. Second, we maintain the simplified computation of the HW metrics of FMEDA by integrating dedicated modeling elements.}
The usage of SystemC-based virtual prototypes for safety analysis is already well established. However, all these approaches focus on simulation of the functionality and injection of errors. For example, in~\cite{reipre_13}, the authors present how virtual prototypes can support the FMEA process. There also exist other works whose main focus is on fault injection during functional simulations~\cite{weisch_16},\cite{tabcha_16},\cite{silpar_14} and \cite{tab_19}. As mentioned above, all of these previous works focus on functional simulation and error injection for ISO\,26262 support. The focus of our work lies on the static hardware metrics analysis of ISO\,26262 and how it can be realized within SystemC. The usage of SystemC-based virtual prototypes for safety analysis is already well established. However, all these approaches focus on simulation of the functionality and injection of errors. For example, in~\cite{reipre_13}, the authors present how virtual prototypes can support the FMEA process. There also exist other works whose main focus is on fault injection during functional simulations~\cite{weisch_16},\cite{tabcha_16},\cite{silpar_14} and \cite{tab_19}. As mentioned above, all of these previous works focus on functional simulation and error injection for ISO\,26262 support. The focus of our work lies on the static hardware metrics analysis of ISO\,26262 and how it can be realized within SystemC.
@@ -419,16 +430,19 @@ In the following, we describe our new methodology for estimating the hardware m
The \textit{Basic Event} block represents internal faults, with a specific failure rate~$\lambda_\mathrm{BE}$. The \textit{Basic Event} block represents internal faults, with a specific failure rate~$\lambda_\mathrm{BE}$.
The \textit{Sum} block receives the failure rates $\lambda_0$ to $\lambda_n$ and computes the sum of these failure rates. The \textit{Sum} block receives the failure rates $\lambda_0$ to $\lambda_n$ and computes the sum of these failure rates.
The \textit{Coverage} block can be used to model the \textit{Diagnostic Coverage}~(DC) of a specific safety measure. The input failure rate $\lambda_\mathrm{in}$ is reduced by the DC rate $c$ of this safety measure: The \textit{Coverage} block can be used to model the \textit{Diagnostic Coverage}~(DC) of a specific safety measure. The input failure rate $\lambda_\mathrm{in}$ is reduced by the DC rate \newer{$c_R$} of this safety measure\newer{, similarly to the already introduced formula in Section~\ref{sec:background}}:
% %
$$\lambda_\mathrm{RF}=\lambda_\mathrm{in}\cdot(1-c)$$ \newer{$$\lambda_\mathrm{RF}=\lambda_\mathrm{in}\cdot(1-c_R)$$}
% %
For instance, if $\lambda=100\,$FIT and $c=0.95$, only 5\,\% of the failures, i.e., $5\,$FIT, are propagated. For instance, if $\lambda=100\,$FIT and \newer{$c_R=0.95$}, only 5\,\% of the failures, i.e., $5\,$FIT, are propagated.
According to the ISO\,26262, the covered FITs must be added to the latent failures $\lambda_\mathrm{MPF,L}$ to consider the scenario where the safety measure is defect: According to the ISO\,26262, \newer{latent failures need also to be considered with their respective coverage.
A low latent coverage denotes that erroneous inputs may be corrected by the safety mechanism, but not propagated back to resolve the root cause of the failure.
The remaining latent failures $\lambda_\mathrm{MPF,L}$ are calculated in a similar manner using the DC rate $c_L$:
% %
$$\lambda_\mathrm{MPF,L}=\lambda_\mathrm{in}\cdot c$$ $$\lambda_\mathrm{MPF,L}=\lambda_\mathrm{in}\cdot(1-c_L)$$
% %
In our example, $95\,$FIT are propagated to the latent fault metrics if no other measure reduces these failures. In our example, if $c_L=0$, all $100\,$FIT are propagated to the latent fault metric.
}%
The \textit{Split} block distributes the incoming failure rate to an arbitrary number of output ports according to specific rates $p_i$, where the condition The \textit{Split} block distributes the incoming failure rate to an arbitrary number of output ports according to specific rates $p_i$, where the condition
% %
@@ -520,7 +534,7 @@ SC_MODULE(sum)
\label{listing:sum} \label{listing:sum}
\end{listing} \end{listing}
% %
The \textit{Coverage} block, shown in Listing~\ref{listing:coverage}, receives the DC as a constructor argument and calculates $\lambda_\mathrm{RF}$ (\texttt{output}) and $\lambda_\mathrm{MPF,L}$ (\texttt{latent}) according to the formulas presented in Section~\ref{sec:method}. The \textit{Coverage} block, shown in Listing~\ref{listing:coverage}, \newer{receives the residual and latent} DC as a constructor argument and calculates $\lambda_\mathrm{RF}$ (\texttt{output}) and $\lambda_\mathrm{MPF,L}$ (\texttt{latent}) according to the formulas presented in Section~\ref{sec:method}.
% %
\begin{listing}[!ht] \begin{listing}[!ht]
\begin{minted}[ \begin{minted}[
@@ -535,9 +549,11 @@ SC_MODULE(coverage)
sc_port<sc_signal_inout_if<double>, 0, SC_ZERO_OR_MORE_BOUND> latent; sc_port<sc_signal_inout_if<double>, 0, SC_ZERO_OR_MORE_BOUND> latent;
double dc; double dc;
double lc;
SC_HAS_PROCESS(coverage); SC_HAS_PROCESS(coverage);
coverage(sc_module_name name, double dc) : input("input"), output("output"), dc(dc) coverage(sc_module_name name, double dc, double lc)
: input("input"), output("output"), dc(dc), lc(lc)
{ {
SC_METHOD(compute_fit); SC_METHOD(compute_fit);
sensitive << input; sensitive << input;
@@ -547,11 +563,11 @@ SC_MODULE(coverage)
{ {
output.write(input.read() * (1 - dc)); output.write(input.read() * (1 - dc));
if (latent.bind_count() != 0) if (latent.bind_count() != 0)
latent->write(input.read() * dc); latent->write(input.read() * (1 - lc);
} }
}; };
\end{minted} \end{minted}
\caption{Implementation of the Coverage Block in SystemC} \caption{\newer{Implementation of the Coverage Block in SystemC}}
\label{listing:coverage} \label{listing:coverage}
\end{listing} \end{listing}
% %
@@ -705,13 +721,13 @@ SC_MODULE(asil)
\draw[blue] (C.bpin 1) to [multiwire] (D3.bpin 12); \draw[blue] (C.bpin 1) to [multiwire] (D3.bpin 12);
\end{circuitikz} \end{circuitikz}
\caption{\new{Memory Architecture of an Automotive SoC similar to Orin~\cite{kar_22}}} \caption{\new{Memory Architecture of an Automotive SoC inspired by Orin~\cite{kar_22}}}
\label{fig:memory_architecture} \label{fig:memory_architecture}
\end{figure} \end{figure}
% %
\new{ \new{
In the original conference paper~\cite{uecjun_22}, we modeled the automotive LPDDR4 DRAM architecture presented in~\cite{stekra_21}. In the original conference paper~\cite{uecjun_22}, we modeled the automotive LPDDR4 DRAM architecture presented in~\cite{stekra_21}.
To show the scalability of our approach, in this work we model a more complex and more recent LPDDR5 memory system, which is similar to NVIDIA's Orin platform~\cite{kar_22}.} To show the scalability of our approach, in this work we model a more complex and more recent LPDDR5 memory system, which is inspired by NVIDIA's Orin platform~\cite{kar_22}.}
%\todo{Show scalability, show benefits of safety analysis with SystemC -> both safety and performance impact of safety measures can be analyzed with the same simulation setup} %\todo{Show scalability, show benefits of safety analysis with SystemC -> both safety and performance impact of safety measures can be analyzed with the same simulation setup}
\new{Compared to its predecessor, LPDDR5 introduces a new \textit{Link Error Correction Code} (Link ECC) feature to reduce the high number of interface errors that occur due to higher data transfer rates.} \new{Compared to its predecessor, LPDDR5 introduces a new \textit{Link Error Correction Code} (Link ECC) feature to reduce the high number of interface errors that occur due to higher data transfer rates.}
@@ -741,8 +757,9 @@ As shown in Figure~\ref{fig:model}, these errors propagate upwards in the system
\new{This SEC ECC is a safety mechanism that can correct all single-bit errors. \new{This SEC ECC is a safety mechanism that can correct all single-bit errors.
Therefore, the SBEs are fully covered, reducing the residual failure rate $\lambda_\mathrm{RF}$ for SBEs to zero. Therefore, the SBEs are fully covered, reducing the residual failure rate $\lambda_\mathrm{RF}$ for SBEs to zero.
This is modeled with the \textit{Coverage} block. This is modeled with the \textit{Coverage} block.
However, if this SEC ECC safety mechanism is defective, the covered failure rate must be added to the latent SBE failure rate $\lambda_\mathrm{MPF,L}$, which propagates to the next component. \newer{However, as the SEC ECC safety mechanism does not correct the fault in the array and has no mechanism to signify the fault to the host, it remains as a latent fault in the array.
Additionally, the failure rate of the SEC ECC itself must be added to the latent failure rate. Consequently, the latent failure rate must be added to the latent SBE failure rate $\lambda_\mathrm{MPF,L}$, which propagates to the next component.
Additionally, if this SEC ECC safety mechanism is defective, the failure rate of the SEC ECC itself must be added to the latent failure rate.}
Therefore, we model an additional \textit{Basic Event} called \textit{SEC ECC Broken} (SB).} Therefore, we model an additional \textit{Basic Event} called \textit{SEC ECC Broken} (SB).}
\new{In case of an incoming DBE, two scenarios have to be differentiated. \new{In case of an incoming DBE, two scenarios have to be differentiated.
@@ -753,23 +770,24 @@ According to~\cite{davkap_81,stekra_21}, 83\,\% of the DBEs stay DBEs, while a t
In order to model this behavior, a \textit{Split} component is used, which distributes the incoming DBE failure rate to DBE and TBE failure rates, respectively. In order to model this behavior, a \textit{Split} component is used, which distributes the incoming DBE failure rate to DBE and TBE failure rates, respectively.
In the case of an incoming MBE and WD, the SEC engine is not able to correct any bit errors. Thus, these failure rates are always propagated.} In the case of an incoming MBE and WD, the SEC engine is not able to correct any bit errors. Thus, these failure rates are always propagated.}
\todo{Compared to LPDDR4, LPDDR5 supports higher data transfer rates at the bus interface, which, in turn, leads to higher bit error rates for the transmission between DRAM controller and device. \new{Compared to LPDDR4, LPDDR5 supports higher data transfer rates at the bus interface, which, in turn, leads to higher bit error rates for the transmission between DRAM controller and device.
For that reason, LPDDR5 introduces a link ECC mechanism, which uses a \textit{Single Error Correction Double Error Detection} (SECDED) code in form of a $(137,128)$ Hamming ECC. New link ECC proposed by Santiago: are all 0 and all 1 valid codewords? Important for AZ error!!!} For that reason, LPDDR5 introduces a link ECC mechanism, which uses a \textit{Single Error Correction Double Error Detection} (SECDED) code in form of a $(137,128)$ Hamming ECC.
\new{Therefore, we analyze the FITs of a typical LPDDR5 interface. \todo{New link ECC proposed by Santiago: are all 0 and all 1 valid codewords? Important for AZ error!!!, AZ kann auf jeden Fall nicht korrigiert werden, maximal erkannt, was aber ohne Retransmission nichts bringt.Future work: SECDED erkennt AZ und macht Retransmission}
\newer{According to the DDR4 JEDEC standard, the interface must fulfill at least a \textit{Bit Error Rate} (BER) of $10^{-16}$ for a single DRAM pin~\cite{jedec2021c}.}} Therefore, we analyze the FITs of a typical LPDDR5 interface.
\newer{As each code word consists of 137 bits, we can compute the probability for multi-bit errors within one code word with \newer{According to the DDR4 JEDEC standard, the interface must fulfill at least a \textit{Bit Error Rate} (BER) of $10^{-16}$ for a single DRAM pin~\cite{jedec2021c}.
Unfortunately, DDR4 is the only standard that includes such a quantified limit, which is why it is referenced instead of the corresponding value for LPDDR.
As each code word consists of 137 bits, we can compute the probability for multi-bit errors within one code word with
\[ p(e) = \binom{n}{e} \cdot \mathrm{BER}^e \cdot \left(1-\mathrm{BER}\right)^{n-e},\] \[ p(e) = \binom{n}{e} \cdot \mathrm{BER}^e \cdot \left(1-\mathrm{BER}\right)^{n-e},\]
where $e$ is the number of errors and $n$ is the number of transmitted bits.} where $e$ is the number of errors and $n$ is the number of transmitted bits.}}
\new{Since the ISO 26262 requires FIT rates for the safety analysis, the probabilities have to be converted. This can be achieved by computing \new{Since the ISO 26262 requires FIT rates for the safety analysis, the probabilities have to be converted. This can be achieved by computing
\[\lambda_\mathrm{Link}(e) = p(e) \cdot \mathrm{DR} \cdot n \cdot \qty{e9}{\hour},\] \[\lambda_\mathrm{Link}(e) = p(e) \cdot \mathrm{DR} \cdot n \cdot \qty{e9}{\hour},\]
where DR is the data transfer rate of the memory, in our case \qty{6400}{\mega\transfer\per\second}. Table~\ref{tab:bus-errors} shows the FIT rates for SBE, DBE, and MBE, where MBE is computed as where DR is the data transfer rate of the memory, in our case \qty{6400}{\mega\transfer\per\second}. Table~\ref{tab:bus-errors} shows the FIT rates for SBE, DBE, and MBE, where MBE is computed as
\[ \mathrm{MBE} = \sum_{e=3}^{16} \lambda_\mathrm{Link}(e).\]} \[ \mathrm{MBE} = \sum_{e=3}^{16} \lambda_\mathrm{Link}(e).\]}
\todo{It is important to highlight that the SBE rate is very large and the DBE and MBE rates can be neglected, i.e., with a BER of $10^{-16}$, it is very unlikely that a DBE or MBE will occur. \new{It is important to highlight that the SBE rate is very large and the DBE and MBE rates can be neglected, i.e., with a BER of $10^{-16}$, it is very unlikely that a DBE or MBE will occur.
Therefore, also Figure~\ref{fig:model} does not include the DBEs and MBEs of the bus. Therefore, also Figure~\ref{fig:model} does not include the DBEs and MBEs of the bus.
This clearly shows the necessity for a SECDED link ECC for high-speed interfaces to make sure that SBEs will be detected and corrected.} This clearly shows the necessity for a SECDED link ECC for high-speed interfaces to make sure that SBEs will be detected and corrected.}
\begin{table}[t] \begin{table}[t]
\centering \centering
\newer{\begin{tblr}{lcc} \newer{\begin{tblr}{lcc}
@@ -855,6 +873,8 @@ This area could be dedicated to additional safety measures and more powerful ECC
\new{There exist further components in the model shown in Figure~\ref{fig:model}. \new{There exist further components in the model shown in Figure~\ref{fig:model}.
For instance, in the DRAM-TRIM component, the redundancy of the code is removed, possibly also reducing the number of data errors. For instance, in the DRAM-TRIM component, the redundancy of the code is removed, possibly also reducing the number of data errors.
\newer{In addition, other components of the system that affect the fault metrics, such as the SoC itself, are modeled using the \textit{Other} component, which contributes \qty{9.5}{FIT} to the residual fault rate as a worst-case assumption.
Consequently, the DRAM is left with a tight budget of \qty{5}{\percent} of the allowed \qty{10}{FIT} for residual faults to achieve ASIL-D.}
For further explanations of these components, we refer to the paper~\cite{stekra_21} and the previous conference paper~\cite{uecjun_22}}. For further explanations of these components, we refer to the paper~\cite{stekra_21} and the previous conference paper~\cite{uecjun_22}}.
% %
\subsection{\new{LPDDR5 Performance Model}} \subsection{\new{LPDDR5 Performance Model}}
@@ -870,17 +890,17 @@ For each bank, the module can hold the data of four ECC requests (redundancy for
\new{Additionally, the addresses of all incoming requests are offset by an incrementing amount to accommodate for the ECC memory regions and the unused space in each DRAM row, as shown in Figure~\ref{fig:in-line}. \new{Additionally, the addresses of all incoming requests are offset by an incrementing amount to accommodate for the ECC memory regions and the unused space in each DRAM row, as shown in Figure~\ref{fig:in-line}.
The offset is derived from the following equations, where $R$ is the original row, $R'$ the new offset row, $C$ the original column and $C'$ the offset column: The offset is derived from the following equations, where $R$ is the original row, $R'$ the new offset row, $C$ the original column and $C'$ the offset column:
% %
\[ \newer{\[
C'=\left(R\cdot 256+C\right)~\mathrm{mod}~1792 C'=\left(R\cdot 128+C\right)~\mathrm{mod}~896
\]} \]}}
\new{\[ \newer{\[
R'=\left\lfloor\frac{R\cdot 256+C}{1792}\right\rfloor+R R'=\left\lfloor\frac{R\cdot 128+C}{896}\right\rfloor+R
\]} \]}
\begin{figure}[p] \begin{figure}[p]
\centering \centering
\include{model} \include{model2}
\caption{\new{Safety Model of a Single LPDDR5 Channel}} \caption{\new{Safety Model of a Single LPDDR5 Channel}}
\label{fig:model} \label{fig:model}
\end{figure} \end{figure}
@@ -905,15 +925,12 @@ In this section, we first discuss the results of the safety analysis and then th
\subsection{Safety Analysis} \subsection{Safety Analysis}
Unlike the state of the art, which only analyzes a single DRAM failure rate, we take our analysis one step further. Unlike the state of the art, which only analyzes a single DRAM failure rate, we take our analysis one step further.
Through the use of SystemC, many different scenarios can be easily computed in parallel. Through the use of SystemC, many different scenarios can be easily computed in parallel.
In order to analyze the safety behavior of the provided DRAM system and the ECC safety measures, the DRAM's failure rate is swept $\lambda_\mathrm{DRAM}$ from 1\,FIT to 2500\,FIT in several simulations. In order to analyze the safety behavior of the provided DRAM system and the ECC safety measures, the DRAM's failure rate is swept $\lambda_\mathrm{DRAM}$ from \newer{0.01\,FIT} to 2500\,FIT in several simulations.
For this simulation, we assume that only the DRAM-related hardware components influence the safety goal under consideration, and leave out other hardware elements on the SoC, which were considered in~\cite{stekra_21}. \newer{As shown in Figure~\ref{fig:absolute}, the requirement for ASIL\,D ($< 10$ FIT) could be reached if the DRAM's failure rate stayed below 2.7\,FIT.
In practice, failure rate budgets are distributed to the involved hardware elements. However, if we take a look at the relative metrics shown in Figure~\ref{fig:relative}, we can see that, with every DRAM fault rate below 304\,FIT, the SPFM threshold of 99\,\% of ASIL\,D could easily be reached.
In this case, as shown in Figure~\ref{fig:absolute}, the requirement for ASIL\,D ($< 10$ FIT) could be reached if the DRAM's failure rate stayed below 53\,FIT. From the LFM perspective, ASIL\,D could also be reached with even higher $\lambda_\mathrm{DRAM}$ rates.
However, if we take a look at the relative metrics shown in Figure~\ref{fig:relative}, we can see that, with a value of 81\,\%, the SPFM is far below the ASIL\,D threshold of 99\,\%. Since both relative and absolute metrics must be met for any ASIL classification, we observe that due to the remaining fault budget of 10\,FIT, the DRAM failure rate $\lambda_\mathrm{DRAM}$ must be below 2.7\,FIT to reach ASIL\,D.
Even ASIL\,B with a SPFM threshold of 90\,\% cannot be reached. Since this very tight budget is well below reported failure rates in the field, current safety measures are not sufficient to achieve ASIL\,D.}
From the LFM perspective, ASIL\,B could be easily reached and even ASIL\,C could be reached for higher $\lambda_\mathrm{DRAM}$ rates.
Since for any ASIL classification both the relative and absolute metrics must be fulfilled, we observe that, independent of the DRAM's failure rate $\lambda_\mathrm{DRAM}$, we cannot achieve a higher level than ASIL\,A.
Thus, it does not help to improve the failure rates of the DRAM technology itself.
\new{Our results for LPDDR5 are similar to the LPDDR4 results of the original conference paper. \new{Our results for LPDDR5 are similar to the LPDDR4 results of the original conference paper.
Although LPDDR5 introduces link ECC as an additional safety measure, it still cannot achieve high ASIL ratings. Although LPDDR5 introduces link ECC as an additional safety measure, it still cannot achieve high ASIL ratings.
It is necessary to introduce more robust and holistic safety measures within the DRAM and the memory controller as well as on software level.} It is necessary to introduce more robust and holistic safety measures within the DRAM and the memory controller as well as on software level.}
@@ -999,8 +1016,6 @@ This means that the channel with in-line ECC can handle around \qty{25}{\percent
\new{In order to establish safety, this is a reasonable performance overhead. \new{In order to establish safety, this is a reasonable performance overhead.
However, since the current safety measures are not sufficient to reach levels above ASIL\,A, it is necessary to add additional safety measures or other coding techniques like \textit{Cyclic Redundancy Check} (CRC) in the future.} However, since the current safety measures are not sufficient to reach levels above ASIL\,A, it is necessary to add additional safety measures or other coding techniques like \textit{Cyclic Redundancy Check} (CRC) in the future.}
% \include{ecc_results}
\begin{figure*}%[h!] \begin{figure*}%[h!]
\begin{subfigure}[b]{0.49\textwidth} \begin{subfigure}[b]{0.49\textwidth}
\centering \centering
@@ -1023,27 +1038,6 @@ However, since the current safety measures are not sufficient to reach levels ab
% Without ECC % Without ECC
\addplot[BrickRed, thick, mark=square, line cap=round, smooth] coordinates { \addplot[BrickRed, thick, mark=square, line cap=round, smooth] coordinates {
% Old
% (6.40 , 31.02) % 25 MHz
% (12.80 , 29.45)
% (19.19 , 29.27)
% (25.58 , 28.69)
% (31.97 , 29.50)
% (38.28 , 29.51)
% (44.73 , 29.38)
% (51.10 , 29.17)
% (56.98 , 29.75)
% (63.77 , 30.17)
% (70.21 , 30.61)
% (76.56 , 31.80)
% (82.91 , 33.01)
% (89.24 , 35.59)
% (95.03 , 42.13)
% (99.49 , 90.34) % 400 MHz
% % (99.49 , 147.20)
% % (99.54 , 153.18)
% % (99.59 , 158.73)
(7.68,30.1) (7.68,30.1)
(14.08,28.9) (14.08,28.9)
(20.48,28.6) (20.48,28.6)
@@ -1064,27 +1058,6 @@ However, since the current safety measures are not sufficient to reach levels ab
% With ECC % With ECC
\addplot[MidnightBlue, thick, mark=square, line cap=round, smooth] coordinates { \addplot[MidnightBlue, thick, mark=square, line cap=round, smooth] coordinates {
% Old
% (6.40 , 31.22) % 25 MHz
% (12.80 , 29.66)
% (19.19 , 29.51)
% (25.58 , 28.90)
% (31.97 , 29.77)
% (38.28 , 29.88)
% (44.73 , 29.94)
% (51.10 , 30.17)
% (56.98 , 31.21)
% (63.77 , 32.06)
% (70.21 , 33.28)
% (76.56 , 35.59)
% (82.86 , 39.22)
% (88.81 , 42.74)
% (91.90 , 60.39)
% (95.86 , 149.22) % 400 MHz
% % (95.86 , 160.59)
% % (95.86 , 163.21)
% % (95.86 , 165.62)
(7.68,31.1) (7.68,31.1)
(14.08,30.0) (14.08,30.0)
(20.48,29.22) (20.48,29.22)
@@ -1136,25 +1109,6 @@ However, since the current safety measures are not sufficient to reach levels ab
% Without ECC % Without ECC
\addplot[BrickRed, thick, mark=square, line cap=round, smooth] coordinates { \addplot[BrickRed, thick, mark=square, line cap=round, smooth] coordinates {
% (6.40 , 48.87) % 25 MHz
% (12.79 , 53.61)
% (19.18 , 59.94)
% (25.51 , 68.33)
% (31.72 , 80.53)
% (37.87 , 98.56)
% (43.84 , 135.89)
% (46.49 , 305.35) % 200 MHz
% (46.83 , 322.82)
% (46.80 , 329.26)
% % (46.84 , 331.94)
% % (46.87 , 333.30)
% % (46.90 , 333.93)
% % (46.90 , 334.75)
% % (46.99 , 335.81)
% (46.90 , 335.50) % 400 MHz
% % (46.90 , 336.52)
% % (47.05 , 336.72)
(1.28,54.7) (1.28,54.7)
(7.68,64.5) (7.68,64.5)
(14.08,71.2) (14.08,71.2)
@@ -1173,25 +1127,6 @@ However, since the current safety measures are not sufficient to reach levels ab
% With ECC % With ECC
\addplot[MidnightBlue, thick, mark=square, line cap=round, smooth] coordinates { \addplot[MidnightBlue, thick, mark=square, line cap=round, smooth] coordinates {
% (6.40 , 53.88) % 25 MHz
% (12.79 , 58.95)
% (19.17 , 66.62)
% (25.50 , 76.68)
% (31.68 , 109.71)
% (33.40 , 440.06) % 150 MHz
% (33.22 , 460.02)
% (33.18 , 469.10)
% % (33.49 , 468.44)
% % (33.47 , 470.61)
% % (33.47 , 472.10)
% % (33.47 , 473.14)
% % (33.47 , 473.94)
% % (33.47 , 474.58)
% % (33.47 , 475.09)
% (33.47 , 475.05) % 400 MHz
% % (33.47 , 475.84)
% % (33.47 , 476.14)
(1.28,59.7) (1.28,59.7)
(7.68,70.22) (7.68,70.22)
(14.08,77.62) (14.08,77.62)

45
model2.tex Normal file
View File

@@ -0,0 +1,45 @@
\resizebox{0.94\textwidth}{!}{%
\begin{circuitikz}
\newcommand{\add}[3]{
\draw(#1) node[draw, circle](#2){$+$};
}
\newcommand{\lane}[4]{
\def\height{#3}
\draw(#1) node[draw, minimum width=16cm, minimum height=\height, outer sep=0, anchor=south west](#2lane){};
\draw(#2lane.west) node[anchor=south, outer sep=0, minimum width=\height,rotate=90](#2lable){#4};
}
% DRAM:
\lane{0,0}{dram}{2.5cm}{DRAM}
\draw(2,1.25) node[draw, circle](wd){WD}; \draw(wd.south) node[anchor=north](){\tiny $172\cdot10^{-9}$};
\draw(5,1.25) node[draw, circle](sbe){SBE}; \draw(sbe.south) node[anchor=north](){\tiny $161\cdot10^{-9}$};
\draw(8.5,1.25) node[draw, circle](dbe){DBE}; \draw(dbe.south) node[anchor=north](){\tiny $172\cdot10^{-9}$};
\draw(12.5,1.25) node[draw, circle](mbe){MBE}; \draw(mbe.south) node[anchor=north](){\tiny $172\cdot10^{-9}$};
% SEC:
\lane{0,3.75}{sec}{3.5cm}{SEC}
\draw[-Triangle,red] (sbe.north) -- (sbe.north|- dramlane.north) node[outport, anchor=south](dramsbeout){};
\draw[-Triangle,red] (wd.north) -- (wd.north |- dramlane.north) node[outport, anchor=south](dramwdout) {};
\draw[-Triangle,red] (dbe.north) -- (dbe.north|- dramlane.north) node[outport, anchor=south](dramdbeout){};
\draw[-Triangle,red] (mbe.north) -- (mbe.north|- dramlane.north) node[outport, anchor=south](drammbeout){};
\draw(dramwdout.north |-seclane.south) node [inport, anchor=north](){};
\draw(dramsbeout.north |-seclane.south) node [inport, anchor=north](secsbein){};
\draw(dramdbeout.north |-seclane.south) node [inport, anchor=north](secdbein){};
\draw(drammbeout.north|-seclane.south) node [inport, anchor=north](){};
\draw[-Triangle,red] (dramsbeout.north) -- (secsbein.south);
\draw[-Triangle,red] (secsbein.north) -- ++(0,0.5) node[coverage, anchor=in](seccov){100\%};
\draw[-Triangle,red] (dramdbeout.north) -- (secdbein.south);
\draw[-Triangle,red] (secdbein.north) -- ++(0,0.5) node[split2, anchor=in, split2 left={83\%}, split2 right={17\%}](secsplit){};
% SEC:
\lane{0,8.5}{trim}{3.5cm}{TRIM}
\draw[-Triangle,red] (seccov.out 1) -- (seccov.out 1|- seclane.north) node[outport, anchor=south](seccovout){};
\draw(seccovout.north|-trimlane.south) node [inport, anchor=north](trimseccovin){};
\draw[-Triangle,red] (seccovout.north) -- (trimseccovin.south);
\draw[-Triangle,red] (trimseccovin.north) -- ++(0,0.5) node[split1, anchor=in, split1 top={94\%}](trimsplit1){};
\draw[-Triangle,red] (secsplit.out 1) -- (secsplit.out 1|- seclane.north) node[outport, anchor=south](secsplitout){};
\draw(secsplitout.north|-trimlane.south) node [inport, anchor=north](secsplitin){};
\draw[-Triangle,red] (secsplitout.north) -- (secsplitin.south);
\draw[-Triangle,red] (secsplitin.north) -- ++(0,0.5) node[split2, anchor=in, split2 left={11\%}, split2 right={89\%}](trimsplit2){};
\draw[-Triangle,red] (secsplit.out 2) -- (secsplit.out 2|- seclane.north) node[outport, anchor=south](secsplitout2){};
\draw[-Triangle,red] (secsplitout2) -- ++(0,0.5) -- ++(2.0,0) coordinate(h) -- (h|-secsplitin.south) node [inport, anchor=south](secsplitin2){};
\draw[-Triangle,red] (secsplitin2.north) -- ++(0,0.5) node[split3, anchor=in, split3 left={0.9\%}, split3 right={83.2\%}, split3 middle={15.8\%}](trimsplit2){};
\end{circuitikz}%
}

20000
random_with_ECC.csv
View File

File diff suppressed because it is too large Load Diff

20000
random_without_ECC.csv
View File

File diff suppressed because it is too large Load Diff

97
result1.tex
View File

@@ -4,7 +4,7 @@
ymode=log, ymode=log,
xlabel={$\lambda_\mathrm{DRAM}$ [FIT]}, xlabel={$\lambda_\mathrm{DRAM}$ [FIT]},
ylabel={$\lambda_\mathrm{out}$ [FIT]}, ylabel={$\lambda_\mathrm{out}$ [FIT]},
xmin=1, xmax=2500, xmin=1e-2, xmax=2500,
ymin=0.1, ymax=800, ymin=0.1, ymax=800,
%xtick={0,20,40,60,80,100}, %xtick={0,20,40,60,80,100},
%ytick={0,20,40,60,80,100,120}, %ytick={0,20,40,60,80,100,120},
@@ -19,51 +19,92 @@
% LPDDR5 RES % LPDDR5 RES
\addplot[smooth,color=red, very thick] \addplot[smooth,color=red, very thick]
coordinates { coordinates {
(1, 0.188034) % (1, 0.188034)
(2, 0.376069) % (2, 0.376069)
(5, 0.940172) % (5, 0.940172)
(10, 1.88034) % (10, 1.88034)
(25, 4.70086) % (25, 4.70086)
(50, 9.40172) % (50, 9.40172)
(100, 18.8034) % (100, 18.8034)
(500, 94.0172) % (500, 94.0172)
(1000, 188.034) % (1000, 188.034)
(2000, 376.069) % (2000, 376.069)
(2500, 470.086) % (2500, 470.086)
(0.01, 9.50188)
(0.0206913808111479, 9.50389)
(0.04281332398719394, 9.50805)
(0.08858667904100823, 9.51666)
(0.18329807108324356, 9.53447)
(0.37926901907322497, 9.57132)
(0.7847599703514611, 9.64756)
(1.623776739188721, 9.80533)
(3.359818286283781, 10.1318)
(6.951927961775605, 10.8072)
(14.38449888287663, 12.2048)
(29.76351441631316, 15.0966)
(61.584821106602604, 21.0801)
(127.42749857031322, 33.4607)
(263.6650898730355, 59.0781)
(545.5594781168514, 112.084)
(1128.8378916846884, 221.76)
(2335.7214690901214, 448.696)
(4832.930238571752, 918.257)
(10000.0, 1889.84)
}; };
% LPDDR5 LAT % LPDDR5 LAT
\addplot[smooth,color=blue, very thick] \addplot[smooth,color=blue, very thick]
coordinates { coordinates {
(1, 0.292388) % (1, 0.292388)
(2, 0.384775) % (2, 0.384775)
(5, 0.661939) % (5, 0.661939)
(10, 1.12388) % (10, 1.12388)
(25, 2.50969) % (25, 2.50969)
(50, 4.81939) % (50, 4.81939)
(100, 9.43877) % (100, 9.43877)
(500, 46.3939) % (500, 46.3939)
(1000, 92.5877) % (1000, 92.5877)
(2000, 184.975) % (2000, 184.975)
(2500, 231.169) % (2500, 231.169)
(0.01, 0.307)
(0.0206913808111479, 0.314484)
(0.04281332398719394, 0.329969)
(0.08858667904100823, 0.362011)
(0.18329807108324356, 0.428309)
(0.37926901907322497, 0.565488)
(0.7847599703514611, 0.849332)
(1.623776739188721, 1.43664)
(3.359818286283781, 2.65187)
(6.951927961775605, 5.16635)
(14.38449888287663, 10.3691)
(29.76351441631316, 21.1345)
(61.584821106602604, 43.4094)
(127.42749857031322, 89.4992)
(263.6650898730355, 184.866)
(545.5594781168514, 382.192)
(1128.8378916846884, 790.487)
(2335.7214690901214, 1635.31)
(4832.930238571752, 3383.35)
}; };
\addplot[smooth,color=red!30, style=dashed] \addplot[smooth,color=red!30, style=dashed]
coordinates { coordinates {
(1, 10) (1e-2, 10)
(2500, 10) (2500, 10)
}; };
\addplot[smooth,color=red!30, style=dashed] \addplot[smooth,color=red!30, style=dashed]
coordinates { coordinates {
(1, 100) (1e-2, 100)
(2500, 100) (2500, 100)
}; };
\node[color=red!30] at (axis cs: 10,15) {ASIL\,D ($\lambda_\mathrm{RF} < 10$)}; \node[color=red!30] at (axis cs: 4,15) {ASIL\,D ($\lambda_\mathrm{RF} < 10$)};
\node[color=red!30] at (axis cs: 60,150) {ASIL\,B/C ($\lambda_\mathrm{RF} < 100$)}; \node[color=red!30] at (axis cs: 30,150) {ASIL\,B/C ($\lambda_\mathrm{RF} < 100$)};
\addplot[thick, samples=50, smooth, red!30, dashed] coordinates {(53,0.1)(53,10)}; \addplot[thick, samples=50, smooth, red!30, dashed] coordinates {(2.66816,0.1)(2.66816,10)};
\legend{ \legend{
$\lambda_\mathrm{RF}$, $\lambda_\mathrm{RF}$,

89
result2.tex
View File

@@ -14,33 +14,75 @@
% LPDDR5 SPFM % LPDDR5 SPFM
\addplot[smooth,color=red, very thick] \addplot[smooth,color=red, very thick]
coordinates { coordinates {
(1, 81.1966) % (1, 81.1966)
(2, 81.1966) % (2, 81.1966)
(5, 81.1966) % (5, 81.1966)
(10, 81.1966) % (10, 81.1966)
(25, 81.1966) % (25, 81.1966)
(50, 81.1966) % (50, 81.1966)
(100, 81.1966) % (100, 81.1966)
(500, 81.1966) % (500, 81.1966)
(1000, 81.1966) % (1000, 81.1966)
(2000, 81.1966) % (2000, 81.1966)
(2500, 81.1966) % (2500, 81.1966)
(1.0, 99.4904)
(1.6237767391887217, 99.4844)
(2.636650898730358, 99.4746)
(4.281332398719393, 99.4588)
(6.951927961775605, 99.4333)
(11.28837891684689, 99.3919)
(18.329807108324356, 99.3251)
(29.76351441631318, 99.2177)
(48.32930238571752, 99.046)
(78.47599703514611, 98.774)
(127.42749857031335, 98.3496)
(206.913808111479, 97.7025)
(335.9818286283781, 96.7497)
(545.5594781168514, 95.4168)
(885.8667904100823, 93.6798)
(1438.449888287663, 91.6135)
(2335.7214690901214, 89.4069)
(3792.690190732246, 87.3055)
(6158.48211066026, 85.5121)
(10000.0, 84.119)
}; };
% LPDDR5 LFM % LPDDR5 LFM
\addplot[smooth,color=blue, very thick] \addplot[smooth,color=blue, very thick]
coordinates { coordinates {
(1, 63.9901) % (1, 63.9901)
(2, 76.3059) % (2, 76.3059)
(5, 83.6954) % (5, 83.6954)
(10, 86.1586) % (10, 86.1586)
(25, 87.6365) % (25, 87.6365)
(50, 88.1291) % (50, 88.1291)
(100, 88.3754) % (100, 88.3754)
(500, 88.5725) % (500, 88.5725)
(1000, 88.5971) % (1000, 88.5971)
(2000, 88.6094) % (2000, 88.6094)
(2500, 88.6119) % (2500, 88.6119)
(1.0, 99.9471)
(1.6237767391887217, 99.9241)
(2.636650898730358, 99.8866)
(4.281332398719393, 99.8259)
(6.951927961775605, 99.7275)
(11.28837891684689, 99.5682)
(18.329807108324356, 99.3109)
(29.76351441631318, 98.8962)
(48.32930238571752, 98.2313)
(78.47599703514611, 97.1736)
(127.42749857031335, 95.5115)
(206.913808111479, 92.9493)
(335.9818286283781, 89.1145)
(545.5594781168514, 83.6214)
(885.8667904100823, 76.2277)
(1438.449888287663, 67.068)
(2335.7214690901214, 56.8182)
(3792.690190732246, 46.5762)
(6158.48211066026, 37.4365)
(10000.0, 30.068)
}; };
\legend{ \legend{
@@ -90,7 +132,8 @@ coordinates {
\node[color=red!30] at (axis cs: 4,92) {\scriptsize ASIL\,B (SPFM $>90\%$)}; \node[color=red!30] at (axis cs: 4,92) {\scriptsize ASIL\,B (SPFM $>90\%$)};
\node[color=red!30] at (axis cs: 15.8,102) {\scriptsize ASIL\,C (SPFM $>97\%$), ASIL-D (SPFM $>99\%$)}; \node[color=red!30] at (axis cs: 15.8,102) {\scriptsize ASIL\,C (SPFM $>97\%$), ASIL-D (SPFM $>99\%$)};
\addplot[thick, samples=50, smooth, blue!30, dashed] coordinates {(3,50)(3,80)}; \addplot[thick, samples=50, smooth, blue!30, dashed] coordinates {(304.25,50)(304.25,90)};
\addplot[thick, samples=50, smooth, red!30, dashed] coordinates {(53.316,50)(53.316,99)};
\end{axis} \end{axis}
\end{tikzpicture} \end{tikzpicture}

20000
seq_with_ECC.csv
View File

File diff suppressed because it is too large Load Diff

20000
seq_without_ECC.csv
View File

File diff suppressed because it is too large Load Diff