tapasco-concepts.7 4.44 KB
Newer Older
Jens Korinth's avatar
Jens Korinth committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
.TH tapasco-concepts 7 "May 11, 2017" "version 2017.1" "MISC"
.SH TAPASCO CONCEPTS / TERMINOLOGY
.TP
.B Compositions
.RS
TaPaSCo generates on-chip microarchitectures for
.I Compositions
consisting of a number of
.I Processing Elements (PEs).
It organizes the PEs according to an
.I Architecture
template, instantiates a
.I Platform
template to provide access to/from the host, memory and a signaling interface
(e.g., interrupts) and performs automatic wiring and pin constraining to
generate a full-system design. All designs generated by TaPaSCo can be
programmed using the
.I Tapasco API
(see tapasco-api.h(3)), i.e., the same software can be run on multiple FPGA
platforms.
.RE

.B TaPaSCo microarchitectures
.RS
The microarchitectures generated by TaPaSCo consist of two parts: The
.I Architecture
and the
.I Platform:
Architecture is resonsible for the organization and wiring of the processing
elements, as well as their control interface. Platform is responsible for
the rest of the design, e.g., the communication to the host, access to
memory, peripherals.
.RE

.B Platform
.RS
Hardware Platform template; each target board (usually) requires its own
Platform template. The Platform defines
.RS 2
.B * the exact part identifier of the FPGA
(e.g., xc7z020clg484-1),
.br
.B * the connection to the host
(e.g., PCIe bridge, AXI master),
.br
.B * the device memory/-ies
(e.g., MIG controller, shared main memory) and
.br
.B * all available optional peripherals (LEDs, sensors, ...)
.RE
.PP
The template is implemented by its main Tcl script (for example, see
$TAPASCO_HOME/platforms/zynq/zynq.tcl). To implement a new Platform, simply
start from an existing one; the \'zc706\' and \'zedboard\' Platforms may be a
good starting point, because they show the minimal interface that is required
(they "inherit" most of their functionality from a common Zynq Tcl).
Hardware generated by the Platform is controlled via the
.I loadable kernel module (LKM)
(or, in general: the device driver) of the Platform and the user space library
above that in libplatform(3).
.RE

.TP
.B Architecture
.RS
Hardware template for the PE organization. The Architecture defines
.RS 2
.B * the control register interface layout
(i.e., PE-local address maps and protocol),
.br
.B * the memory access interface(s) for PEs
(e.g., AXI4-MM masters for memory accesses from PEs),
.br
.B * the signaling interface(s) for PEs
(e.g., level-sensitive interrupt lines),
.B * the automatic wiring and
.br
.B * the interfaces toward the
.I Platform
.RE
.PP
The main Tcl script of the Architecture generates a pre-wired cell called the
\'thread pool\' in which all PEs are instantiated and all their interfaces are
wired to macro-cell inputs/outputs.
.PP
Example: The \'baseline\' Architecture uses AXI4Lite interfaces for the control
registers of the PEs, AXI4-MM master interfaces for memory accesses of the PEs
and single wire, level-sensitive interrupt lines for signaling. The PEs are
connected using AXI Interconnect hierarchies.
.RE

.TP
.B Composition
.RS
Main input to TaPaSCo, a sequence of PEs with their instantiation counts.
TaPaSCo will automatically construct a full-system design from this input.
.RE

.TP
.B Processing Element (PE)
.RS
A hardware IP core that performs a specific computational function. These
are the building blocks of your design in TPC. Each PE is an 
.I instance
of a 
.I Core.
.RE

.TP
.B Core
.RS
A custom IP core described by an IP-XACT [2] description. This is the
file format the Xilinx Vivado IP Integrator uses in its IP Catalog. It usually 
consists of a single .zip file with a \'component.xml\' somewhere inside it,
which provides detailed description of all files, ports and modules of
the IP core. For TaPaSCo, a Core also contains a basic evaluation report,
i.e., an estimation of the area and the worst case data path delay / 
maximal frequency the core can run at, which is device-dependent; therefore
the same 
.I Kernel
may have many Cores, one for each 
.I Platform
and
.I Architecture
combination.
.RE

.TP
.B Target
.RS
Most activities in TaPaSCo require a Target:
A Target is a pair (
.I Architecture
,
.I Platform
).
.RE

.TP
.B Kernel
.RS
Abstract description of a 
.I Core.
More precisely, in TaPaSCo a Kernel is the description of a custom IP core that
can be built via
.I High-Level Synthesis (HLS).
The HLS step will generate a
.I Core
suitable for the selected
.I Target.
.RE

REFERENCES
.RS
[1] http://json.org
.br
[2] http://www.accellera.org/activities/working-groups/ip-xact
.br
[3] http://www.scala-lang.org
.RE