Skip to content

F
FPGA Configuration Space
Commit 6d2a679d authored by Alessandro Rubini's avatar Alessandro Rubini
Browse files
Options

docs: I'm done with the proposal document for this week

parent 1863aa75
Hide whitespace changes
Inline Side-by-side
Showing with 230 additions and 182 deletions
docs/specification/proposal.tex
View file @ 6d2a679d
...@@ -35,17 +35,34 @@ for Logic Cores} ...@@ -35,17 +35,34 @@ for Logic Cores}
\author{Alessandro Rubini (Consultant for CERN)\\ \author{Alessandro Rubini (Consultant for CERN)\\
Wesley Terpstra (GSI),\\ Wesley Terpstra (GSI),\\
Manohar Vanga (CERN, BE/CO/HT)} Manohar Vanga (CERN, BE/CO/HT)}
\date{June 20th 2012} \date{June 21th 2012}
\begin{document} \begin{document}
\maketitle \maketitle
\tableofcontents \tableofcontents
%\listoftables \listoftables
%\listoffigures %\listoffigures
\pagebreak \pagebreak
\section*{Bugs}
This version of this document is still a draft (if it was software, it would be
between \textit{beta} and \textit{release candidate}).
This is a list of things that ought to be changed or added:
\begin{itemize}
\item We should clarify that in nested buses addresses are relative to the sub-bus;
\item The type description should get a more prominent place than the
current description in the \textit{product} structure;
\item We need a policy for designers adding class etc, and it must be described;
\item Wishbone-specific flags deserve a subsection;
\item Filesystem-specific flags must be defined and documented.
\end{itemize}
\section{Introduction} \section{Introduction}
This document describes a specification for a series of self description This document describes a specification for a series of self description
...@@ -471,8 +488,17 @@ A synonym for \textit{SDB structure}. ...@@ -471,8 +488,17 @@ A synonym for \textit{SDB structure}.
An in-memory array of SDB records. The records \textbf{must} An in-memory array of SDB records. The records \textbf{must}
be contiguous with no intervening holes, and the table \textbf{must} be contiguous with no intervening holes, and the table \textbf{must}
be aligned at a 64-byte boundary. be aligned at a 64-byte boundary.
he first SDB structure in the array \textbf{must} be an \textit{interconnect} The first SDB structure in the array \textbf{must} be an \textit{interconnect}
record. record (for this reason, you \textbf{must} verify the \textit{magic number}
of the array before accessing any other location in the array.
\item[Record Type] \hfill \\
The last byte of every SDB structure (offset 0x3f) represents its type.
When reading any SDB structures, unless it is the first in an array,
software \textbf{must} check the \textit{record type} before making sense
of other fields. Designers \textbf{may} extend this specification with
new record types, and software \textbf{must} ignore those structures
whose type is not known.
\item[SDB Product] \hfill \\ \item[SDB Product] \hfill \\
A data structure hosted within some SDB records. All currently defined A data structure hosted within some SDB records. All currently defined
...@@ -486,163 +512,201 @@ includes a \textit{product} structure and defines an address range. ...@@ -486,163 +512,201 @@ includes a \textit{product} structure and defines an address range.
The following sections define the details of each structure. The following sections define the details of each structure.
\subsection{SDB Product Structure} \subsection{SDB Product Structure}
The product is embedded in all currently-defined non-empty data structures.
All multi-byte fields \textbf{must} be stored in big-endian byte order.
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Product Info Structure (40 bytes)}\label{sdwb_product_struct}\centering \caption{SDB Product Structure (40 bytes, at offset 24)}\label{sdb_product}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{5cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 8 & VENDOR\_ID & - & 64-bit vendor ID \\ \hline 0x18 & 0x1f & 8 & vendor\_id & - & 64-bit vendor ID \\ \hline
0x08 & 4 & DEVICE\_ID & - & 32-bit vendor specific device ID \\ \hline 0x20 & 0x23 & 4 & device\_id & - & 32-bit vendor specific device ID \\ \hline
0x0C & 4 & VERSION & - & Vendor specific device version number \\ \hline 0x24 & 0x27 & 4 & version & - & Vendor specific device version number \\ \hline
0x10 & 4 & DATE & - & The release date (hex format, eg. 0x20120601) \\ \hline 0x28 & 0x2b & 4 & date & - & The release date (hex format, eg. 0x20120601) \\ \hline
0x14 & 19 & NAME & - & ASCII device name without NULL terminator \\ \hline 0x2c & 0x3e & 19 & name & - & UTF-8 device name, 0x20 filled, without terminator \\ \hline
0x27 & 1 & RECORD\_TYPE & - & Record type byte (see Table \ref{record_type}) \\ \hline 0x3f & 0x3f & 1 & record\_type & - & Record type byte (see Table \ref{record_type}) \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[VENDOR\_ID] \hfill \\ \item[vendor\_id] \hfill \\
This field provides a 64 bit field that identifies the vendor of the device. The vendor may This field provides a 64 bit field that identifies the vendor of the device. The vendor may
be an company, organization or an individual. The size of this field has been kept at 64 be an company, organization or an individual. The vendor name spaces is split in two halves;
bits to prevent collisions in the long term. anybody \textbf{can} pick a vendor ID in the upper half (first bit set), and the
63 bits \textbf{must} be picked as a random number and \textbf{should} be used consistently
in all the vendor's designs.
A registry is still needed to prevent collisions when using community developed designs from A registry is still needed to prevent collisions when using community developed designs from
multiple sources and one will be set up in the near future. However, use of the registry is multiple sources, and one should be set up as you read this.
not mandated. To allow for this, the 64 bit ID space is split into two parts. All ID's with Entities that want a more official vendor
the most significant bit set are considered free to use. No guarantees are provided regarding ID than a random number, \textbf{should} apply with the current registry using a number of their choice.
collisions when using this space during integration of designs with externally provided Small
components. numbers \textbf{should} be avoided, preferring more meaningful strings instead. The
registry \textbf{should} reject numbers smaller than 12 bits, and \textbf{may} reject numbers
The second part of the ID space with the most significant bit unset is reserved for use with according to policies other than collisions with other vendors.
the registry.
\item[device\_id] \hfill \\
\item[DEVICE\_ID] \hfill \\
This field specifies a manufacturer defined device ID for the device being described. This field specifies a manufacturer defined device ID for the device being described.
Vendors are free to managed these 32 bits as they like, but they \textbf{should} use
\item[VERSION] \hfill \\ the same identifier for fully compatible implementations, using other fields like \textit{version}
This field specifies a manufacturer defined version number for the device. For example, this and \textit{date} to differentiate them.
may be derived from the information provided by the source code management being used.
\item[version] \hfill \\
\item[DATE] \hfill \\ This field specifies a manufacturer defined version number for the device. Vendors
This field specified the release date of the device being described. This must be a 32-bit hex \textbf{can} use the bits as they wish; for example, this \textbf{may} be used sequentially
format number in the format 0xYYYYMMDD. For example, 0x20120101 specifies the first day of the or \textbf{may} be derived from the information provided by the source code management in use
year 2012. for gateware source code.
\item[NAME] \hfill \\
The ASCII name of the device. No NULL terminator need be provided in this field. The name length \item[date] \hfill \\
may be a maximum length of 19 characters. Unused bytes should be set to 0x20 (or ASCII SPACE). Design/release date of the product. This \textbf{must} be either 0 (unspecified) or a 32-bit hex
format number in the format 0xYYYYMMDD. For example, 0x20120501.
\item[RECORD\_TYPE] \hfill \\
Since the product info structure is embedded within various types of record structures, this \item[name] \hfill \\
field specifies the type of the encapsulating structure. There is a record type for each kind The UTF-8 name of the device. As long as the name fits in 19 bytes, designers are free to choose
of SDB record as well as one to specify an empty record. The various record types are described any string (e.g. both ``\texttt{UART}`` or ``\texttt{8250-like Serial}'' are valid names).
in Table \ref{record_type}. The name \textbf{should} be a single word or an hyphenated word, avoiding spaces, because it \textbf{may}
be used by driver software to generate pathnames. The string \textbf{must} start at offset 0
and \textbf{must} be feature value 0x20 (space) in all trailing bytes.
It \textbf{must not} have a trailing zero byte.
\item[record\_type] \hfill \\
Since the product structure is at the end of the SDB record, it includes the
type field. You can access the field from any SDB record, because all records feature
the type byte at offset 0x3f. Software \textbf{must} verify this field before trying to
make sense of any other field in the SDB record.
There is a record type for each kind
of SDB record, and the header file gives it a symbolic name through \texttt{enum}.
The currently defined record types are listed in Table \ref{record_type}. New
record types will most likely enter this specification over time, without the need
to change the SDB version or overall layout. Users adding new record types \textbf{must}
choose a yet-unused value with the hight bit clear for \textit{component} records (0-127);
users adding new record types of informative value (a \textit{product} or a completely
different structure) \textbf{must} choose a yet-unused value with the high bit set (128-255).
Local or temporary uses \textbf{should} fall in the ranges 0x70-0x7f and 0xf0-0xfe.
Software \textbf{should} report a warning when if finds an
unknown record type in the range 0x00-0x7f is found; unknown records in the range 0x80-0xff
\textbf{can} be ignored silently.
\end{description}
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Record Types}\label{record_type}\centering \caption{SDB Record Types}\label{record_type}\centering
\begin{tabular}{| c | l | p{5cm} |} \hline \begin{tabular}{| c | l | p{6cm} |} \hline
Name & Value & Description \\ \hline Name & Value & Description \\ \hline
INTERCONNECT & 0x00 & Interconnect record type \\ \hline sdb\_type\_interconnect & 0x00 & Interconnect record, first of a table \\ \hline
DEVICE & 0x01 & Device record type \\ \hline sdb\_type\_device & 0x01 & Device definition \\ \hline
BRIDGE & 0x02 & Bridge record type \\ \hline sdb\_type\_bridge & 0x02 & Bridge to a sub-bus \\ \hline
INTEGRATOR & 0x80 & Integrator record type \\ \hline & 0x70-0x7f & Local/temporary use \\ \hline
EMPTY & 0xFF & Empty record type \\ \hline sdb\_type\_integration & 0x80 & Informative integration structure \\ \hline
& 0xf0-0xfef & Local/temporary use \\ \hline
sdb\_type\_empty & 0xFF & Empty record \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\end{description}
\subsection{SDB Component Info} \subsection{SDB Component Structure}
The Component Info structure is a 56 byte structure which, in addition to embedding product The SDB Component is described by a data structure that includes \textit{product}
information, also additionally provides information regarding the address space used by the information. It provides information regarding the address space used by the
device. When a particular record type requires address space information in addition to product component it describes.
information, this structure is embedded.
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Component Info Structure (56 bytes)}\label{sdwb_component_struct}\centering \caption{SDB Component Structure (56 bytes, at offset 8)}\label{sdb_component}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{5cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 8 & ADDR\_BEGIN & - & The start address of the component \\ \hline 0x08 & 0x0f & 8 & addr\_first & - & The first valid address of the component \\ \hline
0x08 & 8 & ADDR\_LAST & - & The last valid address of the component \\ \hline 0x10 & 0x17 & 8 & addr\_last & - & The last valid address of the component \\ \hline
0x10 & 40 & PRODUCT & - & SDB Product Info structure (see Table \ref{sdwb_product_struct} \\ \hline 0x18 & 0x3f & 40 & product & - & SDB Product structure (see Table \ref{sdb_product} \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[ADDR\_BEGIN] \hfill \\ \item[addr\_first] \hfill \\
The start address of the memory area occupied by the device. The field \textbf{must} represent the first byte address that belongs to this component,
withing the encompassing bus. If the address bits in the bus are less than 64, the
\item[ADDR\_LAST] \hfill \\ unused most significant bits must be cleared. (e.g.: 0x0000.0000.0400.0000)
The last valid address in memory that is occupied by the device. For example, a device that takes
up the entire 64-bit space has its last address at 0xffffffffffffffff \item[addr\_last] \hfill \\
The field \textbf{must} represent the last byte address that belongs to this component,
\item[PRODUCT] \hfill \\ withing the encompassing bus. If the address bits in the bus are less than 64, the
This is the embedded 40 byte product info structure as described in Table \ref{sdwb_product_struct}. unused most significant bits must be cleared. (e.g.: 0x0000.0000.0400.ffff).
Thus \textbf{must not} represent the first invalid address (e.g.: 0x0000.0000.0401.0000).
\item[product] \hfill \\
This is the embedded 40 byte product info structure as described in Table \ref{sdb_product}.
\end{description} \end{description}
\subsection{SDB Records} \subsection{SDB Records}
This subsection describes the different SDB records that compose the SDB table structure. These This subsection describes the currently defined SDB records that build an SDB array.
These
structures must be instantiated by designers for each logic block in their design and compiled into structures must be instantiated by designers for each logic block in their design and compiled into
a contiguous SDB table that gets placed in the bus memory. a contiguous SDB table, placed at a known address in the bus memory. Most of these structures
include a \textit{component} structure or a \textit{product} structure, and the rules for the
respective fields apply.
\subsubsection{Interconnect Record} \subsubsection{SDB Interconnect}
The interconnect record describes the high level bus that has child devices connected to it. This The \textit{interconnect} record describes the overall bus or bus subset. Every
structure should be the "header" or first record in the SDB table. It provides, among other things, SDB table \textbf{must} feature such structure as first one in the array.
information regarding the SDB table (eg. the number of following records).
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Interconnect Record Structure}\label{sdwb_interconnect_struct}\centering \caption{SDB Interconnect Record (64 bytes, type 0x00)}\label{sdb_interconnect}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{4cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 4 & MAGIC & 0x53445742 & Magic value for checking validity \\ \hline 0x00 & 0x03 & 4 & sdb\_magic & 0x5344422d & ``SDB-'', used to verify a table is actually there \\ \hline
0x04 & 2 & NUM\_RECORDS & - & Number of records in this SDB table \\ \hline 0x04 & 0x05 & 2 & sdb\_records & - & Number of records in this SDB table (including this one) \\ \hline
0x06 & 1 & SDB\_VERSION & 0x1 & SDB format version. Current is 0x1 \\ \hline 0x06 & 0x06 & 1 & sdb\_version & 1 & SDB format version. Currently 1 \\ \hline
0x07 & 1 & SDB\_BUS\_TYPE & - & The last valid address of the component \\ \hline 0x07 & 0x07 & 1 & sdb\_bus\_type & - & The bus type for all components in the table \\ \hline
0x08 & 56 & COMPONENT & - & SDB Component Info structure (see Table \ref{sdwb_component_struct} \\ \hline 0x08 & 0x3f & 56 & sdb\_component & - & SDB Component structure (see Table \ref{sdb_component} \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[MAGIC] \hfill \\ \item[sdb\_magic] \hfill \\
This field is a unique number to ensure that the record being read is valid. The default The field \textbf{must} be set to 0x5344422d. If you use a similar data structure but
value for this in this version of the specification is 0x53445742 or the ASCII characters choose not to fully comply to this standard, you \textbf{must} use a different magic
"SDB". number.
% can people comply with this ``must'' clause, if they choose not to comply with SDB?
\item[NUM\_RECORDS] \hfill \\
This field specifies the number of records in the table. The number must take into account \item[sdb\_records] \hfill \\
this header (interconnect) record as well. The other records following the header may be This field specifies the number of records in the table. It \textbf{must} include
any combination of device, bridge and integrator records. this very record in the count, and the whole address range (this number multplied by 64 bytes)
\textbf{must} be accessible. Note that the array \textbf{may} include empty records at any position.
\item[SDB\_VERSION] \hfill \\
\item[sdb\_version] \hfill \\
This is the record format version. In the current version of the specification this is the This is the record format version. In the current version of the specification this is the
value 0x1. value 0x1. If software finds an unknown version number it \textbf{must} abort enumeration.
\item[SDB\_BUS\_TYPE] \hfill \\ \item[sdb\_bus\_type] \hfill \\
This field specifies the bus type. This field is used when decoding the bus specific information This field specifies the bus type. This field is used when decoding the bus specific information
inside a device record (see below). In the current version of the specification, the only inside a device record (see below). All records in the array share the same
supported bus is Wishbone. Other buses may be added in the future. bus type, bus-specific bits in each device declare the details for data access.
Table \ref{bus_type} lists the currently defined types.
\item[sdb\_component] \hfill \\
An interconnect record describes a \textit{component}, so it embeds a component structure.
The \textit{type} field in the component is 0x00.
\end{description}
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
...@@ -650,143 +714,127 @@ supported bus is Wishbone. Other buses may be added in the future. ...@@ -650,143 +714,127 @@ supported bus is Wishbone. Other buses may be added in the future.
\caption{SDB Bus Types}\label{bus_type}\centering \caption{SDB Bus Types}\label{bus_type}\centering
\begin{tabular}{| c | l | p{5cm} |} \hline \begin{tabular}{| c | l | p{5cm} |} \hline
Name & Value & Description \\ \hline Name & Value & Description \\ \hline
WISHBONE & 0x00 & Specifies a Wishbone bus type \\ \hline WishBone & 0x00 & Specifies a Wishbone bus type, as commonly used in FPGAs \\ \hline
Storage & 0x01 & Specifies use of SDB records as a simple filesystem \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\item[COMPONENT] \hfill \\
An interconnect record has a component info structure embedded within it which can be used
to provide additional meta-data regarding the interconnect itself.
\end{description}
\subsubsection{Integrator Record} \subsubsection{Integration Record}
An integrator record gives meta-data about the aggregate product of the bus. For example, consider An integration record is a \textit{product} record (not a \textit{component}, because
it has no associated address range).
The structure provides meta-data about the aggregate product of the bus or bus subset.
For example, consider
a manufacturer that takes components from various vendors and combines them with a standard bus a manufacturer that takes components from various vendors and combines them with a standard bus
interconnect. This aggregate product can be described by an SDB integrator record. interconnect. This aggregate product can be described by an SDB integration record, claiming
a vendor ID, the release date and the other \textit{product} information.
This record is important as it helps to clearly distinguish product information of devices and of The integrator record is is described in Table \ref{sdb_integrator}.
their aggregated products. Since this is the only main requirement of the integrator record, it
only contains a product info structure without the additional address space information (as this
can easily be gleaned from the records for the specific devices that compose the aggregate). The
structure of the integrator record is described in Table \ref{sdwb_integrator_struct}.
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Integrator Record Structure}\label{sdwb_integrator_struct}\centering \caption{SDB Integrator Record (64 bytes, type 0x80)}\label{sdb_integrator}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{5cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 24 & RESERVED & - & Reserved bytes \\ \hline 0x00 & 0x1f & 24 & reserved & - & Reserved/unused space \\ \hline
0x18 & 40 & PRODUCT & - & SDB Product Info structure (see Table \ref{sdwb_product_struct} \\ \hline 0x18 & 0x3f & 40 & product & - & SDB Product Info structure \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[PRODUCT] \hfill \\ \item[reserved] \hfill \\
An integrator record has a product info structure embedded within it which can be used The initial field in this record is unused, because all needed information is
to provide meta-data that aids in identifying the aggregating interconnect. part of the product structure. Users \textbf{should} fill this area with all bits
clear or all bit set.
\item[product] \hfill \\
This is the \textit{product} structure described in Table \ref{sdb_product}. The
record type for an integration record is 0x80.
\end{description} \end{description}
\subsubsection{Device Record} \subsubsection{Device Record}
This record type describes a single device or logic block mapped into the memory of the This record type describes a single device or logic block mapped into the memory of the
bus. In a correct implementation, one device record should exist for each device that is bus. In a compliant implementation, one device record \textbf{should} exist for each device that is
connected to the bus. The structure of the device record structure is shown below in Table connected to the bus. Users \textbf{may} choose to aggregate a complex device under a single
\ref{sdwb_dev_struct}. description record. The structure of the device record structure is shown below in Table
\ref{sdb_device}.
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Device Record Structure}\label{sdwb_dev_struct}\centering \caption{SDB Device Record (64 bytes, type 0x01)}\label{sdb_device}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{5cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 2 & ABI\_CLASS & - & The ABI class of the device (0 = Custom Device) \\ \hline 0x00 & 0x01 & 2 & abi\_class & - & The ABI class of the device (0 = Custom Device) \\ \hline
0x02 & 1 & ABI\_VER\_MAJOR & - & The ABI major version \\ \hline 0x02 & 0x02 & 1 & abi\_ver\_major & - & The ABI major version \\ \hline
0x03 & 1 & ABI\_VER\_MINOR & - & The ABI minor version \\ \hline 0x03 & 0x03 & 1 & abi\_ver\_minor & - & The ABI minor version \\ \hline
0x04 & 4 & BUS\_SPECIFIC & - & Bus specific field \\ \hline 0x04 & 0x07 & 4 & bus\_specific & - & Bus specific field (flags) \\ \hline
0x08 & 56 & COMPONENT & - & SDB Component Info structure (see Table \ref{sdwb_component_struct} \\ \hline 0x08 & 0x3f & 56 & sdb\_component & - & SDB Component Info structure \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[ABI\_CLASS] \hfill \\ \item[abi\_class] \hfill \\
The ABI class, if specified, tells the kind of standard interface that the device provides. The The ABI class, if not 0, tells the kind of standard interface that the device provides. This
currently available types of ABI classes are specified in Table \ref{abi_class_list}. allows a single driver to deal with compatible devices designed by different vendors, not unlikely
PCI or USB classes. Currently, no ABI class is defined. Designers \textbf{should} use 0 here,
at this point in time.
\begin{center} \item[abi\_ver\_major] \hfill \\
\begin{savenotes}
\begin{table}[!ht]\footnotesize
\caption{ABI Classes}\label{abi_class_list}\centering
\begin{tabular}{| c | l | p{5cm} |} \hline
Value & ABI Class & Description \\ \hline
0 & Custom Device & Used when the device does not conform to any standard interface \\ \hline
\end{tabular}
\end{table}
\end{savenotes}
\end{center}
\item[ABI\_VER\_MAJOR] \hfill \\
This is the major version number of the ABI class. Standard interfaces are not compatible between This is the major version number of the ABI class. Standard interfaces are not compatible between
major version changes. major version changes. If the class is 0, designers \textbf{can} use this field of driver-specific uses. For
example, a driver can be able to deal with a number of similar devices (all with a different device-ID)
and use the ABI fields as a hint to classify the various devices.
\item[ABI\_VER\_MINOR] \hfill \\ \item[abi\_ver\_minor] \hfill \\
This is the minor version number of the ABI class. Standard interfaces are compatible between This is the minor version number of the ABI class. Standard interfaces are compatible between
minor version changes. minor version changes. Again, if the class is 0, developers \textbf{can} set this field for internal use.
\item[BUS\_SPECIFIC] \hfill \\
This is a 4-byte field that holds bus-specific information. The bus specific information for different
supported buses is described in Table \ref{bus_specific}.
\begin{center} \item[bus\_specific] \hfill \\
\begin{savenotes} This is a 4-byte field that holds bus-specific information, most likely flags. Currently, only
\begin{table}[!ht]\footnotesize Wishbone flags are defined; please refer to header files for details.
\caption{Wishbone -- Bus Specific Information}\label{bus_specific}\centering
\begin{tabular}{| c | l | p{5cm} |} \hline
Bit Offset & Name & Description \\ \hline
0 & ENDIAN & Specifies the endianness of the device (0 = big endian, 1 = little endian) \\ \hline
\end{tabular}
\end{table}
\end{savenotes}
\end{center}
\item[COMPONENT] \hfill \\ \item[component] \hfill \\
An embedded component info structure for providing meta-data about the device being described. This is a standard \textit{component} structure (see Table \ref{sdb_component}). The record type
for a device is 0x01.
\end{description} \end{description}
\subsubsection{Bridge Record} \subsubsection{Bridge Record}
A bridge record is used to describe a nested bus within the same address space. This is different from A bridge record is used to describe a nested bus within the same address space. This is different from
a bus controller which provides access to an entirely different address space altogether. Bus a bus controller which provides access to an entirely different address space altogether. Bus
controllers should be treated and handled as devices and not bridges. The structure of the bridge record structures with nested interconnects are typical in complex projects.
is shown in Table \ref{sdwb_bridge_struct}. The structure of the bridge record is shown in Table \ref{sdb_bridge}.
\begin{center} \begin{center}
\begin{savenotes} \begin{savenotes}
\begin{table}[!ht]\footnotesize \begin{table}[!ht]\footnotesize
\caption{SDB Bridge Structure}\label{sdwb_bridge_struct}\centering \caption{SDB Device Record (64 bytes, type 0x02)}\label{sdb_bridge}\centering
\begin{tabular}{| c | c | l | c | p{5cm} |} \hline \begin{tabular}{| c | c | c | l | c | p{5cm} |} \hline
Offset & Size (bytes) & Name & Value & Description \\ \hline First & Last & Size & Name & Value & Description \\ \hline
0x00 & 8 & SDB\_CHILD & - & The relative address of the nested SDB table \\ \hline 0x00 & 0x07 & 8 & sdb\_child & - & The relative address of the nested SDB table \\ \hline
0x08 & 56 & COMPONENT & - & SDB Component Info structure (see Table \ref{sdwb_component_struct} \\ \hline 0x08 & 0x3f & 56 & sdb\_component & - & SDB Component structure \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\end{savenotes} \end{savenotes}
\end{center} \end{center}
\begin{description} \begin{description}
\item[SDB\_CHILD] \hfill \\ \item[sdb\_child] \hfill \\
This field gives the location of the nested bus' SDB table. This address is a relative address This field gives the location of the nested bus' SDB table. This address is a relative address
with respect to the start of the nested bus' address space (stored in the component info structure). with respect to the start of the nested bus' address space (stored in the component info structure).
The value \textbf{must} point to an SDB array that begins with an \textit{interconnect} record.
\item[COMPONENT] \hfill \\ \item[component] \hfill \\
An embedded component info structure for providing meta-data about the bridge being described. An embedded component info structure, where the type is 0x01 See Table \ref{sdb_component}.
\end{description} \end{description}
\end{document} \end{document}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment