Push of additions

PBDSecPaper.tex

@@ -108,6 +108,20 @@ \section{Considerations}
 	\begin{itemize}
 	\item Gain is ease of changes in development and searching of design space
 	\item Loss is time in developing the standards, rigors, and documentation that would be used as new standards for the industry.  Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'')
+	\item Virtualization will help offset the costs in the long game
+		\begin{itemize}
+		\item Essentially, how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block)
+			\begin{itemize}
+			\item A new set of tools that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks
+			\item Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks
+			\item Need for power/energy efficient systems to minimize ``power cost buildup''
+			\item Functions should be kept simple (e.g. decide output, \textbf{but} not how output manifest)
+			\end{itemize}
+		\end{itemize}
+	\item ``Indeed, market data indicate that more than 80% of system development efforts are now in software versus hardware.  This implies that an effective platform has to offer a powerful design environment for software to cope with development cost.''~\cite{Vincentelli2002}
+		\begin{itemize}
+		\item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002}
+		\end{itemize}
 	\end{itemize}
 \item Hardware/Software Codesign
 	\begin{itemize}
@@ -116,7 +130,9 @@ \section{Considerations}
 		\item Codesign of software simulations of hardware allows for development of high level software abstraction to interact with low level hardware abstraction(?)
 		\end{itemize}
 	\item Future considerations (end of Jurgen Teich paper~\cite{Teich2012})
+	\item ``If the functional aspects are indistinguishable from the implementation aspects, then it is very difficult to evolve the design over multiple hardware generations.''~\cite{Vincentelli2007}
 	\end{itemize}
+\item Manufacturer's standpoint boils down to: ``minimize mask-making costs but flexible enough to warrant its use for a set of applications so that production volume will be high over an extended chip lifetime.''~\cite{Vincentelli2007}
 \end{itemize}
 
 \section{Platford-based design}
@@ -125,6 +141,18 @@ \section{Platford-based design}
 \item PBD (Platform-based design)
 	\begin{itemize}
 	\item Monetary considerations: re-use, flexibility of elements, re-programmable
+	\item Design of architecture platform is result of trade-off in complex space.~\cite{Vincentelli2002}
+		\begin{itemize}
+		\item The size of application space that can be supported by the architectures belonging to the architecture platform.  This represents the flexability of the platform.
+		\item The Size of the architecture space that satisfies the constraints embodied in the architecture providers have in designing their hardware instances.
+		\end{itemize}
+	\item Two main concerns for effective platform-based design:
+		\begin{itemize}
+		\item Software development
+		\item Set of tools that insulate the details of architecture from application software
+		\item \textbf{Note Bene:} The more abstract the programmer's model, the richer is the set of platform instances, but the more difficult is to choose the ``optimal'' architecture platform instance and map automatically into it.~\cite{Vincentelli2002}
+		\end{itemize}
+	\item Costs of producing chips becomes more expensive, thus pushing for the systems that are produced to be ``multi-capable'' (e.g. re-use value).~\cite{Keutzer2000}
 	\item ``In PBD, the partitioning of the design into hardware and software is not the essence of system design as many think, tather it is a consequence of decisions taken at a higher level of abstraction.''~\cite{Vincentelli2007}
 		\begin{itemize}
 		\item ``Critical decisions are about the architecture of the system, e.g., processors, buses, hardware accelerators, and memories, that will carry on the computation and communication tasks associated with the overall specification of the design.''~\cite{Vincentelli2007}
@@ -172,6 +200,13 @@ \section{Security}
 	\item Within distributed system
 	\end{itemize}
 \item Mapping of Security onto PBD structure
+\item Automation of security development
+	\begin{itemize}
+	\item Could have security elements that attempt to optimize themselves to the system they are in based on a few pivot points (power, time, efficiency, level of randomness?)
+		\begin{itemize}
+		\item Could trade out specific security components as an easier way to increase security without requireing re-design/re-construction of the underlying element.
+		\end{itemize}
+	\end{itemize}
 \end{itemize}
 
 \section{Conclusion}
@@ -197,7 +232,10 @@ \section{Conclusion}
 \emph{Access policies for middleware}, University of Cambridge (May 2003)
 
 \bibitem{Vincentelli2002} Alberto Sangiovanni-Vincentelli,
-\emph{Defining platform-based design}, http://www.eetimes.com/document.asp?doc_id=1204965
+\emph{Defining platform-based design}, http://www.eetimes.com/document.asp?doc\_id=1204965
+
+\bibitem{Keutzer2000} Kurt Keutzer, Sharad Malik, A.~Richard Newton, Jan M.~Rabaey, and A.~Sangiovanni-Vincentelli,
+\emph{System-Level Design: Orthogonalization of Concerns and Platform-Based Design}, Computer-Aided Design of Integrated Circuits and Systems (Dec 2000)
 
 \end{thebibliography}