Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
S
SDB - Self-describing Bus
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
SDB - Self-describing Bus
Commits
5c8334f6
Commit
5c8334f6
authored
Jun 14, 2012
by
Alessandro Rubini
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
doc: more about the proposal, done up to chapter 2
Signed-off-by:
Alessandro Rubini
<
rubini@gnudd.com
>
parent
7810f473
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
46 additions
and
28 deletions
+46
-28
proposal.tex
docs/specification/proposal.tex
+46
-28
No files found.
docs/specification/proposal.tex
View file @
5c8334f6
...
...
@@ -10,8 +10,11 @@
\usepackage
{
multirow
}
\usepackage
{
footnote
}
\usepackage
{
graphicx
}
\usepackage
{
verbatim
}
\SetWatermarkScale
{
4
}
%\SetWatermarkText{beta version}
\SetWatermarkLightness
{
0.9
}
\usepackage
{
caption
}
\DeclareCaptionFont
{
white
}{
\color
{
white
}}
...
...
@@ -27,8 +30,9 @@
\parskip
10pt
\makesavenoteenv
{
tabular
}
\title
{
Self Descriptive Structures for Logic Cores
}
\author
{
Manohar Vanga (BE/CO/HT), Wesley Terpstra (GSI), Alessandro Rubini (Independent Consultant)
}
\title
{
Self Description Structures for Logic Cores
}
\author
{
Manohar Vanga (BE/CO/HT), Wesley Terpstra (GSI),
\\
Alessandro Rubini (Independent Consultant)
}
\date
{
June 13th 2012
}
\begin{document}
...
...
@@ -42,9 +46,9 @@
\section
{
Introduction
}
This document describes a specification for a series of self descripti
ve
This document describes a specification for a series of self descripti
on
structures that can be used to provide metadata about logic blocks. This metadata
should be provided by the logic cores, like PCI or USB descripti
ve
records,
should be provided by the logic cores, like PCI or USB descripti
on
records,
so device drivers and other software can automatically discover the blocks and
configure them during runtime.
...
...
@@ -141,9 +145,20 @@ computer or network.
\subsection
{
The Overall System Structure
}
The bus described by the structures defined herein is set up as a
fla
g
address space. Our initial target is the
\textit
{
Wishbone
}
bus,
fla
t
address space. Our initial target is the
\textit
{
Wishbone
}
bus,
as used in our own FPGA projects, but the overall situation is
pretty general.
pretty general and can be applied to any bus or even a storage
system for quasi-static information in flash memory
To keep variety to a minimum, this standard defines the concept of
\textit
{
product
}
, which is (anything that has been
\textit
{
done
}
, and thus has
its own identifiers, name, version and date). This includes
meta-information, for example a record of the final build of the
FPGA binary.
Every
\textit
{
product
}
that owns some address space is called a
\textit
{
component
}
; as such it specifies its first and last address, as
64 bit numbers.
Within the bus memory area, the address space available to bus masters
is usually decoded into several blocks using the high address bits, so
...
...
@@ -152,29 +167,30 @@ as powers of two, but this is not mandatory -- some designers may use
individual address lines to select blocks, to easily get a sparsely
populated address space. The designer of the address demultiplexer
(the
\textit
{
interconnect
}
block) is expected to describe the
logic blocks living behind the interconnect, using an array
of data structures (one per sub-block).
Some of those blocks in turn may be bridges to another address
demultiplexer; to support this the structures allow for a different
array of structures to be indexed from any array of structures,
to allow nesting at arbitrary levels.
The structures themselves are expected to be readable at some address
that is part bus itself (i.e., the interconnect blocks are expected to
be able to route bus access to their own internal ROM data).
logic blocks living behind the interconnect, as well as the
interconnect itself. Thus, the
\textit
{
interconnect
}
is a
\textit
{
component
}
(it has an address range), and the associated structure is the first
one of an array of structures, that defines components and optionally
more abstract products.
Some of the blocks within an interconnect data space can in turn be
bridges to another interconnect device. Thus, the
\textit
{
bridge
}
component states where he further self-description structures are to
be found. This allows nesting at arbitrary levels (too deep nesting is
not a good practice, but the specification is not limiting the
designer ingenuity).
Only the bus designer knows where the outer-level data structure is to
be found, and such information is expected to be known b
ut
the ``bus
be found, and such information is expected to be known b
y
the ``bus
driver'' software package. For example, a soft-core scanning its own
bus will know where to start from because it is part of the same
bus will know where to start from
,
because it is part of the same
overall design; a PCI driver must know how to access internal bus
memory from a PCI memory window, so it can also know where the
handle
to self description lives
; an
\textit
{
Etherbone
}
bus master will
memory from a PCI memory window, so it can also know where the
self description entry point is stored
; an
\textit
{
Etherbone
}
bus master will
comply to its own packet-format standard, so it can as well know
where to start enumerating the bus from.
We can therefore define the following
ite
ms to build the
We can therefore define the following
ter
ms to build the
self-description framework:
\begin{description}
...
...
@@ -238,13 +254,13 @@ The same mechanism is soon going to be used in the \textit{White
Rabbit PTP Core
}
and the outer-level FPGA designs that are
being used in our synchronized I/O boards.
\section
{
SD
W
B Header Material
}
\section
{
SDB Header Material
}
This section includes the whole header file
you need to define
the data structures. The header is also part of the associated source files.
%FIXME: header in the sources
This section includes the whole header file
that defines the data
structures. The header is also part of the source code accompanying
this specification.
All fields and bits are explained in
the
later sections of this
All fields and bits are explained in
detail in
later sections of this
specification, but we prefer to show the meat straight at the
beginning, before being lost in acronyms and gory details.
...
...
@@ -252,7 +268,9 @@ This header uses the Linux kernel coding style (e.g.: no \texttt{typedef} is use
but you can write it differently if you prefer -- some of us already did -- as
long as the binary representation of the data matches this one.
%FIXME: header material in the document
\footnotesize
\verbatiminput
{
sdb-h.expand
}
\normalsize
\section
{
SDWB Structures
}
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment