diff --git a/blocks-safety-methodology.tex b/blocks-safety-methodology.tex index a35c3dd..a711d25 100644 --- a/blocks-safety-methodology.tex +++ b/blocks-safety-methodology.tex @@ -67,7 +67,7 @@ \draw (1.375,-0.25) rectangle ++(0.25,0.25); \end{tikzpicture}% } - + % \caption{Calculation Blocks for the Safety Methodology} \label{fig:blocks} \end{figure} \ No newline at end of file diff --git a/blocks.tex b/blocks.tex index df116db..c4e267c 100644 --- a/blocks.tex +++ b/blocks.tex @@ -8,6 +8,9 @@ }} \makeatletter + +\pgfkeys{/tikz/coverage residual/.initial = 100\%} +\pgfkeys{/tikz/coverage latent/.initial = 0\%} \pgfdeclareshape{coverage}{ % Minimum required anchors: \savedanchor{\northeast}{ @@ -20,19 +23,19 @@ } % 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}} + \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{lat} {\northeast \pgfpoint{0.5\pgf@x}{\pgf@y+0.2cm}} + \anchor{res} {\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} @@ -58,6 +61,19 @@ \southwest \pgf@ya=0.5\pgf@y \pgf@xa=0cm \pgftext[at=\pgfpoint{\pgf@xa}{\pgf@ya}]{\bf Coverage} \pgfusepath{stroke} + % Vertical Middle Line: + \northeast \pgf@yb=\pgf@y \pgf@xb=\pgf@x + \pgfpathmoveto{\pgfpoint{0cm}{0cm}} + \pgfpathlineto{\pgfpoint{0cm}{\pgf@yb}} + \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/coverage residual}} + \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/coverage latent}} + \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 diff --git a/main.tex b/main.tex index 944da65..0cbcdf8 100644 --- a/main.tex +++ b/main.tex @@ -42,7 +42,7 @@ %%%% Standard Packages \usepackage[dvipsnames]{xcolor} \newcommand\todo[1]{\textcolor{red}{#1}} -\newcommand\new[1]{\textcolor{blue}{#1}} +\newcommand\new[1]{\textcolor{Cyan}{#1}} \newcommand\newer[1]{\textcolor{Green}{#1}} \newcommand\reviewer[1]{ \textcolor{gray}{\textit{#1}\vspace{0.25cm}} @@ -106,7 +106,8 @@ % Dear Editor, -thank you for the valuable reviews of our journal paper. We revised the paper according to the recommendations of the reviewers. We used the long reviewing time also to further improve the quality and +thank you for the valuable reviews of our journal paper. We revised the paper according to the recommendations of the reviewers. We used the long reviewing time also to further improve the quality and \todo{todo?}. +The additional content of the journal is marked in \new{cyan}, and the additional/updated content of this first revision is marked in \newer{green}. % \subsection*{Reviewer 1} % @@ -177,7 +178,7 @@ We have revised the related work section to more accurately describe the state o Regarding the methodology, it is important to note that the key idea of ISO 26262 follows a different direction - a top down guidance for developing safe hardware. The ASILs are derived based on risks. Depending on the ASIL, the standard requires specific measures and mechanisms to be applied constructively in order to sufficiently reduce the residual probability of failure. The metrics were introduced quite late in the standardization process to verify the sufficiency of the applied mechanisms, but the mere compliance of metrics can't replace following the prescribed development process. For example, for the reuse of existing software, ISO 8926 is currently being developed as a dedicated PAS, as measuring metrics is often not considered sufficient evidence. This does not mean that the authors' approach cannot work, but they should proactively address this aspect and show that they understand the basic idea of ISO 26262. } -\answer{We agree that our proposed methodology cannot replace the development process described in ISO and thank the reviewer for pointing this out. Rather, our approach is intended to more specifically support hardware developers during the design process by eliminating the need for additional translation steps to calculate the ISO required metrics and by facilitating the understanding of the impact of introduced safety mechanisms. Note this is important for a hardware developer (e.g. Tier 1/2) to facilitate a bottom-up integration process where promises (e.g. safety, performance,..) can be provided to system integrators. There are certainly other aspects that go into determining the ASIL level of a HW component with confidence. However, our approach does not claim to be a comprehensive solution in this respect. +\answer{We agree that our proposed methodology cannot replace the development process described in ISO and thank the reviewer for pointing this out. Rather, our approach is intended to more specifically support hardware developers during the design process by eliminating the need for additional translation steps to calculate the ISO required metrics and by facilitating the understanding of the impact of introduced safety mechanisms. Note this is important for a hardware developer (e.g. Tier 1/2) to facilitate a bottom-up integration process where promises (e.g. safety, performance,..) can be provided to system integrators. There are certainly other aspects that go into determining the ASIL of a HW component with confidence. However, our approach does not claim to be a comprehensive solution in this respect. } \reviewer{% @@ -188,8 +189,8 @@ It seems recommendable that the authors either rethink their approach of a rate- \answer{% 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 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. -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. +However, our approach is oriented towards the metrics and analysis performed in the ISO26262. +We not only assume a constant failure rate as denoted in the Section \ref{sec:background} referring to the constant region of the bathtub curve, but we also leverage the calculation principles of the ISO. 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: $$\lambda_{RF} \leq \lambda_{RF,est} = \lambda \cdot \left(1-\frac{K_{DC,RF}}{100\%}\right)$$ @@ -262,7 +263,7 @@ We also agree with the observation that the approximations involved should be mo The development of safe hardware is currently a major concern in the automotive industry. \newer{Due to the high computational and memory requirements of advanced driver-assistance systems and autonomous driving, consumer hardware such as LPDDR DRAM is being deployed in safety-critical areas.} Parts 5 and 11 of ISO\,26262 define procedures and methods for the development of hardware to achieve a specific automotive safety integrity level (ASIL). -\newer{However, consumer devices like LPDDR DRAMs were not originally intended for use in these applications, so they only achieve low ASIL ratings. +\newer{However, consumer devices like LPDDR DRAMs were not originally intended for use in these applications, so they only achieve low ASILs. Additional safety measures can still be added at system level, but this often comes at the cost of reduced performance.} In this paper, we present a novel methodology that combines the hardware metrics analysis of ISO\,26262 with SystemC-based virtual prototyping. \newer{This enables the analysis of a system both from the safety as well as from the performance perspective using the same simulation setup.} @@ -285,14 +286,14 @@ The new methodology is fully implemented in SystemC and provided as open-source. %%\pacs[MSC Classification]{35A01, 65L10, 65L12, 65L20, 65L70} \maketitle - +% % PLAN: % LPDDR4 durch LPDDR5 ersetzen % Neues Systemschaubild % Safety Analyse LPDDR5 % Busfehlerberechung von Kira % Performance Simulation von Derek --> Vorteile Orthogonale Simulation aufzeigen - +% \newer{\section{Introduction}} \label{sec:intro} Functional safety is a major concern in the development of automotive applications because the lives of drivers, passengers, and other road users must be protected to the highest degree. @@ -306,7 +307,7 @@ Parts 5 and 11 of the standard in particular deal with the development processes For the development of a product, it is therefore very important to address safety concerns already from the beginning. State-of-the-art approaches used to estimate hardware metrics are based on spreadsheets and do not scale well to large hardware systems. \newer{In addition, because consumer hardware such as LPDDR DRAM was originally intended for a different domain, no specific automotive safety requirements were considered during design. -This means that the devices themselves usually only achieve a low ASIL rating. +This means that the devices themselves usually only achieve a low ASIL. Additional safety measures can be introduced at the system level in order to achieve the required safety goals for the entire platform. However, they add more complexity and can negatively impact performance. In the case of DRAM, this means lower bandwidth, higher latency, and reduced capacity. @@ -324,7 +325,7 @@ The presented method receives failure rates in \textit{Failure in Time}~(FIT) an \newer{In this journal version, we update the safety analysis of our previous work~\cite{uecjun_22} from LPDDR4 to LPDDR5 and extend it with an associated performance analysis. As a case study, we investigate the LPDDR5 memory subsystem of a current platform for automotive applications. -LPDDR5 features more safety measures than its predecessor, and the platform adds additional error correction on system level. +LPDDR5 offers more error correction than its predecessor, and the platform adds additional system-level error correction. By combining functional and safety simulations with SystemC, we show the impact of these safety measures on performance.} \noindent In summary, we make the following contributions: @@ -357,8 +358,8 @@ As shown in Figure~\ref{fig:bathtube}, hardware failure rates $\lambda(t)$ usual \caption{Hardware Failure Bathtub Curve~\cite{iso26262}} \label{fig:bathtube} \end{figure} -\newpage -For the analysis of hardware failures, the ISO\,26262 assumes that the hardware is used during its useful lifetime and that the failure rate $\lambda(t)$ is constant (see ISO\,26262-11~\cite{iso26262}). + +For the analysis of hardware failures, ISO\,26262 assumes that the hardware is used during its useful lifetime and that the failure rate $\lambda(t)$ is constant (see ISO\,26262-11~\cite{iso26262}). % For constant failure rates, we can assume the exponential failure distribution $$F(t) = 1 - e^{-\lambda\cdot t}$$ @@ -366,10 +367,10 @@ $$F(t) = 1 - e^{-\lambda\cdot t}$$ The constant failure rate of this distribution $\lambda$ is measured in \textit{Failure in Time} (FIT), where 1~FIT represents one failure in $10^9$ hours, which is approximately one failure in 114,080 years. For the hardware metrics, ISO\,26262 distinguishes several different failure rates, among them: \begin{itemize} - \item $\lambda_\mathrm{SPF}$ \textit{Single-Point Fault Failure Rate}: Considers faults that are not covered by any safety mechanism and immediately lead to the violation of a safety goal. - \item $\lambda_\mathrm{RF}$ \textit{Residual Fault Failure Rate}: Considers faults where a safety mechanism is implemented, but is not controlled by the safety mechanism and leads to the violation of a safety goal. - \item $\lambda_\mathrm{MPF}$ \textit{Multi-Point Fault Failure Rate}: Considers several independent faults, which in combination lead to the violation of a safety goal. For this paper, especially the latent faults $\lambda_\mathrm{MPF,L}$ are important, whose presence is neither detected by a safety mechanism nor perceived by the driver. - \item $\lambda_\mathrm{S}$ \textit{Safe Fault Failure Rate}: Considers faults that do not have any significant influence on the violation of a safety goal. + \item \textit{Single-Point Fault Failure Rate} ($\lambda_\mathrm{SPF}$): Considers faults that are not covered by any safety mechanism and immediately lead to the violation of a safety goal. + \item \textit{Residual Fault Failure Rate} ($\lambda_\mathrm{RF}$): Considers faults where a safety mechanism is implemented, but is not controlled by the safety mechanism and leads to the violation of a safety goal. + \item \textit{Multi-Point Fault Failure Rate} ($\lambda_\mathrm{MPF}$): Considers several independent faults, which in combination lead to the violation of a safety goal. For this paper, especially the latent faults $\lambda_\mathrm{MPF,L}$ are important, whose presence is neither detected by a safety mechanism nor perceived by the driver. + \item \textit{Safe Fault Failure Rate} ($\lambda_\mathrm{S}$): Considers faults that do not have any significant influence on the violation of a safety goal. \end{itemize} \noindent The total failure rate is the sum of the above failure rates: @@ -377,86 +378,112 @@ $$\lambda = \lambda_\mathrm{SPF} + \lambda_\mathrm{RF} + \lambda_\mathrm{MPF} + % \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: +In order to calculate $\lambda_{RF}$ of a safety mechanism, 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: +ISO\,26262 furthermore specifies the hardware metrics used to evaluate the risk posed by hardware elements: \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 \textit{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. $$ \mathrm{SPFM} = 1 - \frac{\sum \left( \lambda_\mathrm{SPF} + \lambda_\mathrm{RF}\right)}{\sum \lambda}$$ - \item[Latent Fault Metric (LFM):] + \item \textit{Latent Fault Metric} (LFM): This metric reflects the coverage of an hardware element with respect to latent faults either by design (primarily safe faults), fault coverage via safety mechanisms, or by the driver’s recognition of a fault’s existence within the fault-tolerant time interval of a safety goal. $$ \mathrm{LFM} = 1 - \frac{\sum \lambda_\mathrm{MPF,L}}{\sum \left(\lambda - \lambda_\mathrm{SPF} - \lambda_\mathrm{RF}\right)}$$ \end{description} \begin{table}[t] \centering + \caption{Requirements according to ISO\,26262~\cite{iso26262}} \begin{tblr}{cccc} \hline - \textbf{ASIL} & \textbf{SPFM} & \textbf{LFM} & \textbf{Residual FIT} \\ \hline + \textbf{ASIL} & \textbf{SPFM} & \textbf{LFM} & \textbf{Residual FIT} \\ + \hline \textbf{A} & - & - & $< 1000$ \\ \textbf{B} & $> 90\%$ & $> 60\%$ & $< 100 $ \\ \textbf{C} & $> 97\%$ & $> 80\%$ & $< 100 $ \\ \textbf{D} & $> 99\%$ & $> 90\%$ & $< 10 $ \\ \hline \end{tblr} - \vspace{10pt} - \caption{Requirements according to ISO\,26262~\cite{iso26262}} \label{tab:target} \end{table} -Table \ref{tab:target} shows the required target values for $\lambda_\mathrm{RF}$, SPFM, and LFM to reach a specific ASIL. For example, the highest rating ASIL\,D can only be reached if the SPFM is greater than 99\%, the LFM is greater than 90\%, and the residual failure rate is below 10. +Table~\ref{tab:target} shows the required target values for $\lambda_\mathrm{RF}$, SPFM, and LFM to reach a specific ASIL. For example, the highest certification ASIL\,D can only be reached if the SPFM is greater than 99\%, the LFM is greater than 90\%, and the residual failure rate is below 10. \section{Related Work} \label{sec:related} % This section discusses related work and the state of the art. -\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.} +\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.} -\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 only needed when high assurance levels are required, and in part because they can be more demanding from a modeling perspective. The latter is especially 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.} +\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 only needed when high assurance levels are required, and in part because they can be more demanding from a modeling perspective. +The latter is especially true for Markov Chains, as the models can grow very rapidly, resulting in models that are difficult to understand and maintain. +Fault Trees, and in particular the Component Fault Trees (CFT) introduced by Kaiser et\,al.~\cite{kailig_03}, provide 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.} -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 show 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. % % -\include{blocks-safety-methodology} % \section{Methodology} \label{sec:method} -In the following, we describe our new methodology for estimating the hardware metrics required by ISO\,26262. Similar to CFTs, our methodology is object-oriented, i.e., it models the system with the hardware components that also exist in reality. The safety behavior of each component is modeled in the component itself by using five central building blocks, which are shown in Figure~\ref{fig:blocks} and explained below. +In the following, we describe our new methodology for estimating the hardware metrics required by ISO\,26262. +Similar to CFTs, our methodology is object-oriented, i.e., it models the system with the hardware components that also exist in reality. +The safety behavior of each component is modeled in the component itself by using five central building blocks, which are shown in Figure~\ref{fig:blocks} and explained below. +% +\input{blocks-safety-methodology} -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{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}}: +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{, similar to the formula in Section~\ref{sec:background}}: % \newer{$$\lambda_\mathrm{RF}=\lambda_\mathrm{in}\cdot(1-c_R)$$} % -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, \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$: +For instance, if $\lambda=100\,$FIT and \newer{$c_R=0.95$}, only 5\,\% of the faults, i.e., $5\,$FIT, are propagated. +According to ISO\,26262, \newer{latent faults also need 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 fault. +The remaining latent faults $\lambda_\mathrm{MPF,L}$ are calculated in a similar manner using the DC rate $c_L$: % $$\lambda_\mathrm{MPF,L}=\lambda_\mathrm{in}\cdot(1-c_L)$$ % 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 % $$\sum_{i=0}^{n} p_i \leq 1$$ % -must hold; otherwise, new failures would be created out of nowhere. It is possible for some parts of the incoming failure rate to completely vanish because of the split, i.e., they are not propagated. These faults are called \textit{Safe Faults} because they will never lead to a safety goal violation. The safe fault failure rate can therefore be described as: +must hold; otherwise, new faults would be created out of nowhere. It is possible for some parts of the incoming failure rate to completely vanish because of the split, i.e., they are not propagated. These faults are called \textit{Safe Faults} because they will never lead to a safety goal violation. The safe fault failure rate can therefore be described as: $$\lambda_{S} = \lambda_\mathrm{in} \cdot \left(1-\sum_{i=0}^{n} p_i \right)$$ -In summary, the \textit{Split} block is used to model failure distributions caused by the system structure, e.g., when a data stream is divided, or when the safety mechanism adds additional errors during the correction of unsupported faults, such as double-bit errors in a single-error correction mechanism. - +In summary, the \textit{Split} block is used to model fault distributions caused by the system structure, e.g., when a data stream is divided, or when the safety mechanism adds additional errors during the correction of unsupported faults, such as double-bit errors in a single-error correction mechanism. The last required block is the \textit{ASIL} block, which calculates the ASIL from the $\lambda_\mathrm{SPF}$, $\lambda_\mathrm{RF}$, and $\lambda_\mathrm{MPF,L}$ within the entire system. This block implements the logic of Table~\ref{tab:target}. -With these five blocks, it is possible to model the safety behavior of hardware in compliance with the ISO\,26262. We would like to mention here that it is only necessary to consider faults of safety-related components. Components that are not safety related do not have to be modeled at all, or their errors do not need to be modeled or connected (and thus not considered in the sum of all errors). +With these five blocks, it is possible to model the safety behavior of hardware in compliance with ISO\,26262. We would like to mention here that it is only necessary to consider faults of safety-related components. Components that are not safety related do not have to be modeled at all, or their errors do not need to be modeled or connected (and thus not considered in the sum of all errors). In Section~\ref{sec:study}, we present the modeling of a real-world automotive memory system in order to understand the interaction of these blocks. % % @@ -469,268 +496,269 @@ Therefore, there are already many functional simulation models that can be enhan SystemC offers the right infrastructure by providing the concept of modules, ports, and signals that are required for our basic blocks. Unlike graphical safety tools, it also offers programmability, and repetitions can be handled by loops. Furthermore, SystemC's port check is very helpful in the development phase of the safety model, since it will complain about unbound ports at the beginning of a simulation. -The failure rates are propagated by using a classical \texttt{sc\_signal}. +The failure rates are propagated through a classical \texttt{sc\_signal}. For all blocks, we use the dynamic binding of SystemC for the sake of convenience. All blocks contain classical \texttt{SC\_METHOD}s, i.e., during the first delta cycles of the SystemC simulation, all hardware safety measures are already calculated and are printed out at the end of a simulation. -The first block is the \textit{Basic Event} block shown in Listing~\ref{listing:basic_event}, which receives the failure rate (\texttt{rate}) as a constructor argument and propagates this value to its output port. -\begin{listing}[!ht] - \begin{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -SC_MODULE(basic_event) -{ - sc_out output; - double rate; - - SC_HAS_PROCESS(basic_event); - basic_event(sc_module_name name, double rate) : output("output"), rate(rate) - { - SC_METHOD(compute_fit); - } - - void compute_fit() - { - output.write(rate); - } -}; - \end{minted} - \caption{Implementation of the Basic Event Block in SystemC} - \label{listing:basic_event} -\end{listing} +The first block is the \textit{Basic Event} block shown in Listing~\ref{listing:basic_event} in the \hyperref[sec:appendix]{Appendix} of the paper. +It receives the failure rate (\texttt{rate}) as a constructor argument and propagates this value to its output port. +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%SC_MODULE(basic_event) +%{ +% sc_out output; +% double rate; +% +% SC_HAS_PROCESS(basic_event); +% basic_event(sc_module_name name, double rate) : output("output"), rate(rate) +% { +% SC_METHOD(compute_fit); +% } +% +% void compute_fit() +% { +% output.write(rate); +% } +%}; +% \end{minted} +% \caption{Implementation of the Basic Event Block in SystemC} +% \label{listing:basic_event} +%\end{listing} % The \textit{Sum} block has a dynamic input port array and a single output port. In its computation method, it calculates the sum of the incoming failure rates on all input ports, as shown in Listing~\ref{listing:sum}. % -\begin{listing}[!ht] - \begin{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -SC_MODULE(sum) -{ - sc_port, 0, SC_ONE_OR_MORE_BOUND> inputs; - sc_out output; - - SC_CTOR(sum) : output("output") - { - SC_METHOD(compute_fit); - sensitive << inputs; - } - - void compute_fit() - { - double sum = 0.0; - for (int i = 0; i < inputs.size(); i++) - sum += inputs[i]->read(); - output.write(sum); - } -}; - \end{minted} - \caption{Implementation of the Sum Block in SystemC} - \label{listing:sum} -\end{listing} +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%SC_MODULE(sum) +%{ +% sc_port, 0, SC_ONE_OR_MORE_BOUND> inputs; +% sc_out output; +% +% SC_CTOR(sum) : output("output") +% { +% SC_METHOD(compute_fit); +% sensitive << inputs; +% } +% +% void compute_fit() +% { +% double sum = 0.0; +% for (int i = 0; i < inputs.size(); i++) +% sum += inputs[i]->read(); +% output.write(sum); +% } +%}; +% \end{minted} +% \caption{Implementation of the Sum Block in SystemC} +% \label{listing:sum} +%\end{listing} % 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{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -SC_MODULE(coverage) -{ - sc_in input; - sc_out output; - sc_port, 0, SC_ZERO_OR_MORE_BOUND> latent; - - double dc; - double lc; - - SC_HAS_PROCESS(coverage); - coverage(sc_module_name name, double dc, double lc) - : input("input"), output("output"), dc(dc), lc(lc) - { - SC_METHOD(compute_fit); - sensitive << input; - } - - void compute_fit() - { - output.write(input.read() * (1 - dc)); - if (latent.bind_count() != 0) - latent->write(input.read() * (1 - lc); - } -}; - \end{minted} - \caption{\newer{Implementation of the Coverage Block in SystemC}} - \label{listing:coverage} -\end{listing} +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%SC_MODULE(coverage) +%{ +% sc_in input; +% sc_out output; +% sc_port, 0, SC_ZERO_OR_MORE_BOUND> latent; +% +% double dc; +% double lc; +% +% SC_HAS_PROCESS(coverage); +% coverage(sc_module_name name, double dc, double lc) +% : input("input"), output("output"), dc(dc), lc(lc) +% { +% SC_METHOD(compute_fit); +% sensitive << input; +% } +% +% void compute_fit() +% { +% output.write(input.read() * (1 - dc)); +% if (latent.bind_count() != 0) +% latent->write(input.read() * (1 - lc); +% } +%}; +% \end{minted} +% \caption{\newer{Implementation of the Coverage Block in SystemC}} +% \label{listing:coverage} +%\end{listing} % Compared to the other blocks, the implementation of the \textit{Split} block is more complex. Since we want to support dynamic binding and direct assignment of the failure distribution rate, we derived a custom \texttt{sc\_split\_port} from \texttt{sc\_port} that overwrites the \texttt{bind} methods in order to allow specifying the split rate directly with the dynamic binding, as shown in Listing~\ref{listing:port}. % -\begin{listing}[!ht] - \begin{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -template -class sc_split_out : public sc_port, 0, SC_ONE_OR_MORE_BOUND> -{ -public: - std::vector split_rates; - - void bind(sc_interface& interface, double rate) - { - sc_port_base::bind(interface); - split_rates.push_back(rate); - } - - void bind(sc_out& parent, double rate) - { - sc_port_base::bind(parent); - split_rates.push_back(rate); - } -}; - \end{minted} - \caption{Implementation of the Custom Split Port in SystemC} - \label{listing:port} -\end{listing} +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%template +%class sc_split_out : public sc_port, 0, SC_ONE_OR_MORE_BOUND> +%{ +%public: +% std::vector split_rates; +% +% void bind(sc_interface& interface, double rate) +% { +% sc_port_base::bind(interface); +% split_rates.push_back(rate); +% } +% +% void bind(sc_out& parent, double rate) +% { +% sc_port_base::bind(parent); +% split_rates.push_back(rate); +% } +%}; +% \end{minted} +% \caption{Implementation of the Custom Split Port in SystemC} +% \label{listing:port} +%\end{listing} % The actual implementation of the \textit{Split} component is shown in Listing~\ref{listing:split}. It receives a failure rate as input and distributes it to the output ports according to the assigned split rates. % -\begin{listing}[!ht] - \begin{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -SC_MODULE(split) -{ - sc_in input; - sc_split_out outputs; - - SC_CTOR(split) : input("input") - { - SC_METHOD(compute_fit); - sensitive << input; - } - - void compute_fit() - { - for (int i = 0; i < outputs.size(); i++) - { - double rate = outputs.split_rates.at(i); - outputs[i]->write(input.read() * rate); - } - } -}; - \end{minted} - \caption{Implementation of the Split Block in SystemC} - \label{listing:split} -\end{listing} - +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%SC_MODULE(split) +%{ +% sc_in input; +% sc_split_out outputs; +% +% SC_CTOR(split) : input("input") +% { +% SC_METHOD(compute_fit); +% sensitive << input; +% } +% +% void compute_fit() +% { +% for (int i = 0; i < outputs.size(); i++) +% { +% double rate = outputs.split_rates.at(i); +% outputs[i]->write(input.read() * rate); +% } +% } +%}; +% \end{minted} +% \caption{Implementation of the Split Block in SystemC} +% \label{listing:split} +%\end{listing} +% The last building block is the \textit{ASIL} block, which estimates the ASIL of the system according to Table~\ref{tab:target}. -It receives the single point and residual failure rates $\lambda_\mathrm{SPF} +\lambda_\mathrm{RF}$ and the latent failure rates $\lambda_\mathrm{MPF,L}$ as input. -Furthermore, it receives the total failure rate $\lambda$ as input, calculates the ASIL level, and prints it in the overridden \texttt{end\_of\_simulation()} callback function of the module as shown in Listing~\ref{listing:asil}. +It receives the sum of single point and residual fault failure rates $\lambda_\mathrm{SPF} +\lambda_\mathrm{RF}$ and the latent fault failure rates $\lambda_\mathrm{MPF,L}$ as inputs. +Furthermore, it receives the total failure rate $\lambda$ as input, calculates the ASIL, and prints it in the overridden \texttt{end\_of\_simulation} callback function of the module as shown in Listing~\ref{listing:asil}. % -\begin{listing}[!ht] - \begin{minted}[ - bgcolor=LightGray, - fontsize=\footnotesize, - linenos - ]{c++} -SC_MODULE(asil) -{ - sc_in residual; - sc_in latent; - - double spfm; - double lfm; - std::string system_asil; - double total; - - SC_HAS_PROCESS(asil); - asil(sc_module_name name, double total) : total(total) - { - SC_METHOD(compute); - sensitive << residual << latent; - } - - void compute() - { - spfm = 100 * (1 - (residual / total)); - lfm = 100 * (1 - (latent / (total - residual))); - - if (spfm > 99.0 && lfm > 90.0 && residual < 10.0) - system_asil = "ASIL D"; - else if (spfm > 97.0 && lfm > 80.0 && residual < 100.0) - system_asil = "ASIL C"; - else if (spfm > 90.0 && lfm > 60.0 && residual < 100.0) - system_asil = "ASIL B"; - else if (residual < 1000.0) - system_asil = "ASIL A"; - else - system_asil = "QM"; - } - - void end_of_simulation() override - { - // Printout of the estimated system ASIL... - } -}; - \end{minted} - \caption{Implementation of the ASIL Block in SystemC} - \label{listing:asil} -\end{listing} +%\begin{listing}[!ht] +% \begin{minted}[ +% bgcolor=LightGray, +% fontsize=\footnotesize, +% linenos +% ]{c++} +%SC_MODULE(asil) +%{ +% sc_in residual; +% sc_in latent; % -\newpage +% double spfm; +% double lfm; +% std::string system_asil; +% double total; +% +% SC_HAS_PROCESS(asil); +% asil(sc_module_name name, double total) : total(total) +% { +% SC_METHOD(compute); +% sensitive << residual << latent; +% } +% +% void compute() +% { +% spfm = 100 * (1 - (residual / total)); +% lfm = 100 * (1 - (latent / (total - residual))); +% +% if (spfm > 99.0 && lfm > 90.0 && residual < 10.0) +% system_asil = "ASIL D"; +% else if (spfm > 97.0 && lfm > 80.0 && residual < 100.0) +% system_asil = "ASIL C"; +% else if (spfm > 90.0 && lfm > 60.0 && residual < 100.0) +% system_asil = "ASIL B"; +% else if (residual < 1000.0) +% system_asil = "ASIL A"; +% else +% system_asil = "QM"; +% } +% +% void end_of_simulation() override +% { +% // Printout of the estimated system ASIL... +% } +%}; +% \end{minted} +% \caption{Implementation of the ASIL Block in SystemC} +% \label{listing:asil} +%\end{listing} +% +%\newpage % \section{\new{Case Study with LPDDR5}} \label{sec:study} % -\begin{figure} - \centering - \begin{circuitikz} - \useasboundingbox (-5.5,-5.5) rectangle (5.5,5.5); - \draw[blue] (0,0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](C){SoC}; - \draw[blue] ( 0, 4) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D1){LPDDR5}; - \draw[blue] ( 0,-4) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D2){LPDDR5}; - \draw[blue] (-4, 0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D3){LPDDR5}; - \draw[blue] ( 4, 0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D4){LPDDR5}; - \draw[blue] (C.bpin 16) to [multiwire=16] (D1.bpin 5); - \draw[blue] (C.bpin 15) to [multiwire] (D1.bpin 6); - \draw[blue] (C.bpin 14) to [multiwire] (D1.bpin 7); - \draw[blue] (C.bpin 13) to [multiwire] (D1.bpin 8); - \draw[blue] (C.bpin 12) to [multiwire=16] (D4.bpin 1); - \draw[blue] (C.bpin 11) to [multiwire] (D4.bpin 2); - \draw[blue] (C.bpin 10) to [multiwire] (D4.bpin 3); - \draw[blue] (C.bpin 9) to [multiwire] (D4.bpin 4); - \draw[blue] (C.bpin 8) to [multiwire=16] (D2.bpin 13); - \draw[blue] (C.bpin 7) to [multiwire] (D2.bpin 14); - \draw[blue] (C.bpin 6) to [multiwire] (D2.bpin 15); - \draw[blue] (C.bpin 5) to [multiwire] (D2.bpin 16); - \draw[blue] (C.bpin 4) to [multiwire=16] (D3.bpin 9); - \draw[blue] (C.bpin 3) to [multiwire] (D3.bpin 10); - \draw[blue] (C.bpin 2) to [multiwire] (D3.bpin 11); - \draw[blue] (C.bpin 1) to [multiwire] (D3.bpin 12); - \end{circuitikz} - - \caption{\new{Memory Architecture of an Automotive SoC inspired by Orin~\cite{kar_22}}} - \label{fig:memory_architecture} -\end{figure} -% \new{ 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 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} \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.} +\begin{figure} + \centering + \begin{circuitikz} + \useasboundingbox (-5.5,-5.5) rectangle (5.5,5.5); + \draw[Cyan] (0,0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](C){SoC}; + \draw[Cyan] ( 0, 4) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D1){LPDDR5}; + \draw[Cyan] ( 0,-4) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D2){LPDDR5}; + \draw[Cyan] (-4, 0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D3){LPDDR5}; + \draw[Cyan] ( 4, 0) node[qfpchip, num pins=16, hide numbers, no topmark, external pins width=0](D4){LPDDR5}; + \draw[Cyan] (C.bpin 16) to [multiwire=16] (D1.bpin 5); + \draw[Cyan] (C.bpin 15) to [multiwire] (D1.bpin 6); + \draw[Cyan] (C.bpin 14) to [multiwire] (D1.bpin 7); + \draw[Cyan] (C.bpin 13) to [multiwire] (D1.bpin 8); + \draw[Cyan] (C.bpin 12) to [multiwire=16] (D4.bpin 1); + \draw[Cyan] (C.bpin 11) to [multiwire] (D4.bpin 2); + \draw[Cyan] (C.bpin 10) to [multiwire] (D4.bpin 3); + \draw[Cyan] (C.bpin 9) to [multiwire] (D4.bpin 4); + \draw[Cyan] (C.bpin 8) to [multiwire=16] (D2.bpin 13); + \draw[Cyan] (C.bpin 7) to [multiwire] (D2.bpin 14); + \draw[Cyan] (C.bpin 6) to [multiwire] (D2.bpin 15); + \draw[Cyan] (C.bpin 5) to [multiwire] (D2.bpin 16); + \draw[Cyan] (C.bpin 4) to [multiwire=16] (D3.bpin 9); + \draw[Cyan] (C.bpin 3) to [multiwire] (D3.bpin 10); + \draw[Cyan] (C.bpin 2) to [multiwire] (D3.bpin 11); + \draw[Cyan] (C.bpin 1) to [multiwire] (D3.bpin 12); + \end{circuitikz} + + \caption{\new{Memory Architecture of an Automotive SoC inspired by Orin~\cite{kar_22}}} + \label{fig:memory_architecture} +\end{figure} +% \newer{Figure~\ref{fig:memory_architecture} shows the system architecture, which consists of a high-performance \textit{System on Chip} (SoC) and four LPDDR5-6400 devices. Each memory device comprises four independent 16-bit channels, which in total results in 16 channels and a 256-bit memory interface with a theoretical maximum bandwidth of \qty{204.8}{\giga\byte\per\second} for the entire control unit. To further increase data reliability, the platform is equipped with an in-line ECC mechanism. @@ -740,7 +768,7 @@ Since LPDDR5 does not offer additional metadata bits like, e.g., HBM3, and the p In addition to the reduced memory capacity, the in-line ECC has a negative impact on the DRAM performance (bandwidth and latency). Redundancy has to be transmitted separately from user data, while with side-band ECC it is transmitted in parallel. In the worst case, each user data access must be accompanied by an additional redundancy access. -To estimate the performance overhead of the in-line ECC technique, in Section~\ref{sec:vp}, we model the platform's DRAM subsystem within the DRAM simulator DRAMSys~\cite{junwei_15,stejun_20}. +To estimate the performance implications of the in-line ECC technique, in Section~\ref{sec:vp}, we model the platform's DRAM subsystem within the DRAM simulator DRAMSys~\cite{junwei_15,stejun_20}. Like the safety model, DRAMSys is based on SystemC, so the system can be analyzed from both perspectives within the same simulation.} % % @@ -755,11 +783,11 @@ The exact distribution of these errors and failure rates was obtained from \text As shown in Figure~\ref{fig:model}, these errors propagate upwards in the system to the next component, the internal LPDDR5 \textit{Single Error Correction} (SEC), which uses a $(136,128)$ Hamming ECC.} % \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 fault failure rate $\lambda_\mathrm{RF}$ for SBEs to zero. This is modeled with the \textit{Coverage} block. -\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. -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.} +\newer{However, as the SEC ECC safety mechanism does not correct the fault in the array and has no mechanism to signal the fault to the host, it remains as a latent fault in the array. +Consequently, the latent fault 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 fault failure rate.} 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. @@ -772,13 +800,13 @@ In the case of an incoming MBE and WD, the SEC engine is not able to correct any \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. -\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} +%\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} Therefore, we analyze the FITs of a typical LPDDR5 interface. \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 +With the assumption that individual single-bit errors on the interface are statistically independent, 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},\] -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, i.e., in our case 137.}} \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},\] @@ -790,6 +818,7 @@ This clearly shows the necessity for a SECDED link ECC for high-speed interfaces \begin{table}[t] \centering + \caption{\new{Bus Failure Rates}} \newer{\begin{tblr}{lcc} \hline \textbf{Number of Errors ($e$)} & \textbf{$p(e)$} & \textbf{$\lambda_\mathrm{Link}(e)$} \\\hline @@ -798,8 +827,6 @@ This clearly shows the necessity for a SECDED link ECC for high-speed interfaces 3-16 (MBE) & $4.192\cdot10^{-43}$ & $1.545\cdot10^{-19}$ \\ % 4.192e-43 \hline \end{tblr}} - \vspace{10pt} - \caption{\new{Bus Failure Rates}} \label{tab:bus-errors} \end{table} @@ -867,14 +894,14 @@ Since the corresponding parity bits are stored in the same row, the additional E In Section~\ref{sec:results}, we discuss the performance overhead for the best and worst case scenarios. The used ECC is a (272, 256) Hamming SECDED with 16 bits redundancy per DRAM access. % -Since the redundancy is not stored in an additional chip or in additional metadata bits, the effective memory size is reduced by \qty{12.5}{\percent}. +Because the redundancy is not stored in an additional chip or in additional metadata bits, but in-line instead of user data, the effective memory size is reduced by \qty{12.5}{\percent}. Moreover, as shown in Figure~\ref{fig:in-line}, 4.5 DRAM accesses per row are currently unused. This area could be dedicated to additional safety measures and more powerful ECC algorithms in the future.} \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. -\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.} +\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 failure 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}}. % \subsection{\new{LPDDR5 Performance Model}} @@ -898,22 +925,23 @@ The offset is derived from the following equations, where $R$ is the original ro R'=\left\lfloor\frac{R\cdot 128+C}{896}\right\rfloor+R \]} -\begin{figure}[p] +\begin{figure} \centering - \include{model2} + \input{model2} + \vspace{10cm} \caption{\new{Safety Model of a Single LPDDR5 Channel}} \label{fig:model} \end{figure} -\begin{figure}[p] +\begin{figure} \centering - \include{result1} + \input{result1} \caption{Absolute (LPDDR5)} \label{fig:absolute} \end{figure} -\begin{figure}[p] +\begin{figure} \centering - \include{result2} + \input{result2} \caption{Relative (LPDDR5)} \label{fig:relative} \end{figure} @@ -923,21 +951,21 @@ The offset is derived from the following equations, where $R$ is the original ro In this section, we first discuss the results of the safety analysis and then the results of the performance 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 fault rate, we take our analysis one step further. 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 \newer{0.01\,FIT} to 2500\,FIT in several simulations. -\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. -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. -From the LFM perspective, ASIL\,D could also be reached with even higher $\lambda_\mathrm{DRAM}$ rates. -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. -Since this very tight budget is well below reported failure rates in the field, current safety measures are not sufficient to achieve ASIL\,D.} -\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. -It is necessary to introduce more robust and holistic safety measures within the DRAM and the memory controller as well as on software level.} -\todo{...Link ECC is only able to correct errors that happen on the bus. Parity bits are calculated directly before transmission and correction is done directly after transmission. Errors that are in the data before transmission (e.g., errors from the array) are just propagated and are still in the data after transmission. Original paper considered lower error rates for link and only MBE, in this paper we distinguish between SBE/DBE/MBE, LP4 has higher VDDQ and lower data rates (max 4266 vs max 6400 for LP5 and 8533 for LP5X), AZ error rate is the same and dominant, SBE of LP5 are corrected by link ECC, only small influence on final result, what about latent failures of link ECC coverage block?} - +In order to analyze the safety behavior of the provided DRAM system and the ECC safety measures, the DRAM's fault rate $\lambda_\mathrm{DRAM}$ is swept from \newer{0.01\,FIT} to 2500\,FIT in several simulations. +\newer{As shown in Figure~\ref{fig:absolute}, the requirement for ASIL\,D ($< 10$ FIT) is reached if the DRAM's fault rate stays below 2.7\,FIT. +If we take a look at the relative metrics shown in Figure~\ref{fig:relative}, we see that even with a DRAM fault rate below 304\,FIT, the SPFM threshold of 99\,\% of ASIL\,D can be reached easily. +From the LFM perspective, ASIL\,D can be reached with even higher $\lambda_\mathrm{DRAM}$. +Since both relative and absolute metrics must be met for any ASIL certification, we observe that, due to the remaining fault budget of 10\,FIT, the DRAM fault rate $\lambda_\mathrm{DRAM}$ must be below 2.7\,FIT to reach ASIL\,D. +This is well below reported failure rates in the field, so current safety measures are not sufficient to achieve ASIL\,D.} +\newer{While the newly added link ECC feature helps address interface errors that become more severe as data rates increase and I/O voltages decrease, it does not change how $\lambda_\mathrm{DRAM}$ propagates through the DRAM subsystem. +Thus, our results for LPDDR5 are similar to the LPDDR4 results of the original conference paper. +For a higher ASIL certification, it is necessary to introduce more robust and holistic safety measures within the DRAM and the memory controller as well as on software level.} +%\todo{...Link ECC is only able to correct errors that happen on the bus. Parity bits are calculated directly before transmission and correction is done directly after transmission. Errors that are in the data before transmission (e.g., errors from the array) are just propagated and are still in the data after transmission. Original paper considered lower error rates for link and only MBE, in this paper we distinguish between SBE/DBE/MBE, LP4 has higher VDDQ and lower data rates (max 4266 vs max 6400 for LP5 and 8533 for LP5X), AZ error rate is the same and dominant, SBE of LP5 are corrected by link ECC, only small influence on final result, what about latent failures of link ECC coverage block?} +% This confirms the results presented by \cite{stekra_21}, \cite{buc_20} for single scenarios. -They also conclude that with the current ECC safety measures, no higher rating than ASIL\,A can be achieved. +They also conclude that with the current ECC safety measures, no higher certification than ASIL\,A can be achieved. Since it is unlikely that future DRAM technologies will lead to a decrease in the failure rates, it is very important to introduce further safety measures to make the DRAM system ready for future ASIL requirements. \subsection{Performance Analysis} @@ -959,11 +987,10 @@ When the DRAM is stressed with a worst case scenario, i.e., a fully random acces With enabled ECC, the bandwidth drops by another \newer{\qty{13}{\percent}} to \newer{\qty{33.51}{\giga\bit\per\second}}. In this case, the drop is greater because each user data access requires an additional ECC access. \newer{At the very least, this ECC access is always a row hit. -When the ECC-enabled bandwidth is set in direct relation to the original bandwidth utilization}, it even corresponds to a decrease of \qty{29}{\percent}, i.e., for random traffic the DRAM channel loses almost one third of its performance due to the additional safety measure. -} +When the ECC-enabled bandwidth is set in direct relation to the original bandwidth utilization}, it even corresponds to a decrease of \qty{29}{\percent}, i.e., for random traffic the DRAM channel loses almost one third of its performance due to the additional safety measure.} %This is due to the high row miss rate and the additional ECC memory accesses. -\begin{figure}[t!] +\begin{figure} \centering \begin{tikzpicture} \begin{axis}[ @@ -989,9 +1016,9 @@ When the ECC-enabled bandwidth is set in direct relation to the original bandwid \label{fig:bandwdith} \end{figure} % - +% % \new{Furthermore, we analyzed the impact of the ECC on latency. The Figures~\ref{fig:linear-wo-ecc}, \ref{fig:linear-w-ecc}, \ref{fig:rand-wo-ecc} and \ref{fig:rand-w-ecc} show the latency histograms for the four investigated scenarios. It can be observed that the latency is only weakly affected in the sequential case, whereas in the random case, the distribution is shifted more towards higher latencies once ECC is enabled. The average latency for the sequential access pattern is \qty{162.4}{\nano\second} without ECC and \qty{168.2}{\nano\second} when ECC is enabled (\qty{3.4}{\percent} increase), whereas for the random case the average latency is \qty{344.3}{\nano\second} without ECC and increases to \qty{487.5}{\nano\second} with ECC (\qty{29.4}{\percent} increase).} - +% \new{Furthermore, we analyze the impact of the in-line ECC on latency. To do this, the frequency that requests are issued to the DRAM subsystem is varied from \qty{25}{\mega\hertz} in increasing steps of \qty{25}{\mega\hertz} to \qty{400}{\mega\hertz}, which is the maximum a channel with a data rate of \qty{6400}{\mega\transfer\per\second} and a burst length of 16 can theoretically handle. The Figures~\ref{fig:lat_bw:linear} and \ref{fig:lat_bw:random} plot the average response latency of all requests over the bandwidth for the four investigated scenarios. @@ -1171,7 +1198,7 @@ However, since the current safety measures are not sufficient to reach levels ab \section{Conclusion and Future Work} \label{sec:conclusion} -In this paper, we presented a new methodology for modeling the safety behavior of modern hardware systems in compliance with the ISO\,26262 automotive standard. The implementation of this new methodology is provided as an open-source SystemC library and can be used to enhance legacy models with safety and quality analysis. In order to demonstrate the power of this new methodology, we modeled a state-of-the-art automotive DRAM memory architecture. Based on this model, we simulated a continuous space of failure rates of the DRAM system. We conclude that with the current safety measures, it is not possible to achieve a rating higher than ASIL\,A. \new{Furthermore, we combined the safety simulation with a functional simulation, such that the overhead of the safety measures could be estimated quickly. In fact, we see a storage overhead of \qty{12.5}{\percent} and a bandwidth overhead of \newer{\qty{6}{\percent}} in the best case and \newer{\qty{29}{\percent}} in the worst case. In the future, we will analyze new safety measures that could help reaching the goal of an ASIL\,D certification by using the presented methodology.} +In this paper, we presented a new methodology for modeling the safety behavior of modern hardware systems in compliance with the ISO\,26262 automotive standard. The implementation of this new methodology is provided as an open-source SystemC library and can be used to enhance legacy models with safety and quality analysis. In order to demonstrate the power of this new methodology, we modeled a state-of-the-art automotive DRAM memory architecture. Based on this model, we simulated a continuous space of failure rates of the DRAM system. We conclude that with the current safety measures, it is not possible to achieve a certification higher than ASIL\,A. \new{Furthermore, we combined the safety simulation with a functional simulation, such that the overhead of the safety measures could be estimated quickly. In fact, we see a storage overhead of \qty{12.5}{\percent} and a bandwidth overhead of \newer{\qty{6}{\percent}} in the best case and \newer{\qty{29}{\percent}} in the worst case. In the future, we will analyze new safety measures that could help reaching the goal of an ASIL\,D certification by using the presented methodology.} % \section*{Author's Contributions} All authors contributed to all parts of the paper. @@ -1187,4 +1214,212 @@ There are no acknowledgements at this time. % \bibliography{references_JR.bib}% common bib file % +\newpage +\section*{Appendix} +\label{sec:appendix} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +SC_MODULE(basic_event) +{ + sc_out output; + double rate; + + SC_HAS_PROCESS(basic_event); + basic_event(sc_module_name name, double rate) : output("output"), rate(rate) + { + SC_METHOD(compute_fit); + } + + void compute_fit() + { + output.write(rate); + } +}; + \end{minted} + \caption{Implementation of the Basic Event Block in SystemC} + \label{listing:basic_event} +\end{listing} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +SC_MODULE(sum) +{ + sc_port, 0, SC_ONE_OR_MORE_BOUND> inputs; + sc_out output; + + SC_CTOR(sum) : output("output") + { + SC_METHOD(compute_fit); + sensitive << inputs; + } + + void compute_fit() + { + double sum = 0.0; + for (int i = 0; i < inputs.size(); i++) + sum += inputs[i]->read(); + output.write(sum); + } +}; + \end{minted} + \caption{Implementation of the Sum Block in SystemC} + \label{listing:sum} +\end{listing} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +SC_MODULE(coverage) +{ + sc_in input; + sc_out output; + sc_port, 0, SC_ZERO_OR_MORE_BOUND> latent; + + double dc; + double lc; + + SC_HAS_PROCESS(coverage); + coverage(sc_module_name name, double dc, double lc) + : input("input"), output("output"), dc(dc), lc(lc) + { + SC_METHOD(compute_fit); + sensitive << input; + } + + void compute_fit() + { + output.write(input.read() * (1 - dc)); + if (latent.bind_count() != 0) + latent->write(input.read() * (1 - lc); + } +}; + \end{minted} + \caption{\newer{Implementation of the Coverage Block in SystemC}} + \label{listing:coverage} +\end{listing} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +template +class sc_split_out : public sc_port, 0, SC_ONE_OR_MORE_BOUND> +{ +public: + std::vector split_rates; + + void bind(sc_interface& interface, double rate) + { + sc_port_base::bind(interface); + split_rates.push_back(rate); + } + + void bind(sc_out& parent, double rate) + { + sc_port_base::bind(parent); + split_rates.push_back(rate); + } +}; + \end{minted} + \caption{Implementation of the Custom Split Port in SystemC} + \label{listing:port} +\end{listing} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +SC_MODULE(split) +{ + sc_in input; + sc_split_out outputs; + + SC_CTOR(split) : input("input") + { + SC_METHOD(compute_fit); + sensitive << input; + } + + void compute_fit() + { + for (int i = 0; i < outputs.size(); i++) + { + double rate = outputs.split_rates.at(i); + outputs[i]->write(input.read() * rate); + } + } +}; + \end{minted} + \caption{Implementation of the Split Block in SystemC} + \label{listing:split} +\end{listing} +% +\begin{listing}[h] + \begin{minted}[ + bgcolor=LightGray, + fontsize=\footnotesize, + linenos + ]{c++} +SC_MODULE(asil) +{ + sc_in residual; + sc_in latent; + + double spfm; + double lfm; + std::string system_asil; + double total; + + SC_HAS_PROCESS(asil); + asil(sc_module_name name, double total) : total(total) + { + SC_METHOD(compute); + sensitive << residual << latent; + } + + void compute() + { + spfm = 100 * (1 - (residual / total)); + lfm = 100 * (1 - (latent / (total - residual))); + + if (spfm > 99.0 && lfm > 90.0 && residual < 10.0) + system_asil = "ASIL D"; + else if (spfm > 97.0 && lfm > 80.0 && residual < 100.0) + system_asil = "ASIL C"; + else if (spfm > 90.0 && lfm > 60.0 && residual < 100.0) + system_asil = "ASIL B"; + else if (residual < 1000.0) + system_asil = "ASIL A"; + else + system_asil = "QM"; + } + + void end_of_simulation() override + { + // Printout of the estimated system ASIL... + } +}; + \end{minted} + \caption{Implementation of the ASIL Block in SystemC} + \label{listing:asil} +\end{listing} +% +% +% \end{document} diff --git a/model2.tex b/model2.tex index 04885ab..6b48175 100644 --- a/model2.tex +++ b/model2.tex @@ -1,8 +1,11 @@ \resizebox{0.94\textwidth}{!}{% \begin{circuitikz} - \newcommand{\add}[3]{ + \newcommand{\add}[2]{ \draw(#1) node[draw, circle](#2){$+$}; } + \newcommand{\basicevent}[4]{ + \draw #1 node[draw, circle,inner sep=0,minimum size=1cm](#2){#3} ++(0,-0.5) node[anchor=north](){\tiny $#4$}; + } \newcommand{\lane}[4]{ \def\height{#3} \draw(#1) node[draw, minimum width=16cm, minimum height=\height, outer sep=0, anchor=south west](#2lane){}; @@ -10,36 +13,75 @@ } % 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}$}; + %outputs + \draw (dramlane.north) ++(-5.25,0) node[outport, anchor=south](dram_wd_out){}; + \draw (dramlane.north) ++(-1.75,0) node[outport, anchor=south](dram_sbe_out) {}; + \draw (dramlane.north) ++(+1.75,0) node[outport, anchor=south](dram_dbe_out){}; + \draw (dramlane.north) ++(+5.25,0) node[outport, anchor=south](dram_mbe_out){}; + % blocks + \basicevent{(dram_wd_out) ++(0,-1.25)}{wd}{WD}{172} + \basicevent{(dram_sbe_out) ++(0,-1.25)}{sbe}{SBE}{1610} + \basicevent{(dram_dbe_out) ++(0,-1.25)}{dbe}{DBE}{172} + \basicevent{(dram_mbe_out) ++(0,-1.25)}{mbe}{MBE}{172} + % inner connections + \draw[-Triangle,red] (wd.north) -- (dram_wd_out); + \draw[-Triangle,red] (sbe.north) -- (dram_sbe_out); + \draw[-Triangle,red] (dbe.north) -- (dram_dbe_out); + \draw[-Triangle,red] (mbe.north) -- (dram_mbe_out); + % 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: + % inputs + \draw (seclane.south) ++(-5.25,0) node[inport, anchor=north](sec_wd_in){}; + \draw (seclane.south) ++(-1.75,0) node[inport, anchor=north](sec_sbe_in) {}; + \draw (seclane.south) ++(+1.75,0) node[inport, anchor=north](sec_dbe_in){}; + \draw (seclane.south) ++(+5.25,0) node[inport, anchor=north](sec_mbe_in){}; + % outputs + \draw (seclane.north) ++(-5.25,0) node[outport, anchor=south](sec_wd_out){}; + \draw (seclane.north) ++(-2.5,0) node[outport, anchor=south](sec_sbe_out){}; + \draw (seclane.north) ++(-1.0,0) node[outport, anchor=south](sec_sbe_lat_out){}; + \draw (seclane.north) ++(1,0) node[outport, anchor=south](sec_dbe_out){}; + \draw (seclane.north) ++(2.5,0) node[outport, anchor=south](sec_tbe_out){}; + \draw (seclane.north) ++(5.25,0) node[outport, anchor=south](sec_mbe_out){}; + \draw (seclane.north) ++(+7,0) node[outport, anchor=south](sec_sb_out){}; + % blocks + \draw (sec_sbe_in.north) ++(0,0.5) node[coverage, anchor=in, coverage residual=10\%, coverage latent=12\%] (seccov){}; + \draw (sec_dbe_in.north) ++(0,0.5) node[split2, anchor=in, split2 left=83\%, split2 right=17\%] (secsplit){}; + % \draw[-Triangle,red] (sec_sbe_in.north) -- ++(0,0.5) node[coverage, anchor=in, coverage residual=10\%, coverage latent=12\%](seccov){}; + % \draw[-Triangle,red] (sec_dbe_in.north) -- ++(0,0.5) node[split2, anchor=in, split2 left={83\%}, split2 right={17\%}](secsplit){}; + \basicevent{(sec_sb_out) ++(0,-1.5)}{sb}{SB}{0.1} + % inner connections + \draw[-Triangle,red] (sec_wd_in) -- (sec_wd_out); + \draw[-Triangle,red] (sec_mbe_in) -- (sec_mbe_out); + \draw[-Triangle,red] (secsplit.out 1) -- (sec_dbe_out); + \draw[-Triangle,red] (secsplit.out 2) -- (sec_tbe_out); + \draw[-Triangle,red] (sec_sbe_in) -- (seccov.in); + \draw[-Triangle,red] (sec_dbe_in) -- (secsplit.in); + \draw[-Triangle,red] (seccov.res) -- (sec_sbe_out); + \draw[-Triangle,blue] (seccov.lat) -- (sec_sbe_lat_out); + \draw[-Triangle,blue] (sb) -- (sec_sb_out); + + % dram -> SEC + \draw[-Triangle,red] (dram_wd_out.north) -- (sec_wd_in.south) node[anchor=east,midway,align=center]{WD \\ \tiny TODO}; + \draw[-Triangle,red] (dram_sbe_out.north) -- (sec_sbe_in.south) node[anchor=east,midway,align=center]{SBE \\ \tiny TODO}; + \draw[-Triangle,red] (dram_dbe_out.north) -- (sec_dbe_in.south) node[anchor=east,midway,align=center]{DBE \\ \tiny TODO}; + \draw[-Triangle,red] (dram_mbe_out.north) -- (sec_mbe_in.south) node[anchor=east,midway,align=center]{MBE \\ \tiny TODO}; + + % DRAM-TRIM: \lane{0,8.5}{trim}{3.5cm}{TRIM} - \draw[-Triangle,red] (seccov.out 1) -- (seccov.out 1|- seclane.north) node[outport, anchor=south](seccovout){}; + % inputs \draw(seccovout.north|-trimlane.south) node [inport, anchor=north](trimseccovin){}; - \draw[-Triangle,red] (seccovout.north) -- (trimseccovin.south); + \draw(sec_sbe_out.north|-trimlane.south) node [inport, anchor=north](secsplitin){}; + % blocks \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){}; + % outputs + + % \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){}; + + % sec -> DRAM-TRIM + % \draw[-Triangle,red] (seccovout.north) -- (trimseccovin.south); + % \draw[-Triangle,red] (secsplitout.north) -- (secsplitin.south); \end{circuitikz}% } \ No newline at end of file