Repository navigation
Expand file tree
/
Copy pathTAC_BASIC_TECHNICAL_Addressing_PAGE.html
More file actions
197 lines (195 loc) · 20.8 KB
/
Copy pathTAC_BASIC_TECHNICAL_Addressing_PAGE.html
File metadata and controls
197 lines (195 loc) · 20.8 KB
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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.17"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>TAC V0.0.4 @ 2021.03.25: BASIC module placing and addressing</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(document).ready(function() { init_search(); });
/* @license-end */
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
extensions: ["tex2jax.js", "TeX/AMSmath.js", "TeX/AMSsymbols.js"],
jax: ["input/TeX","output/HTML-CSS"],
});
</script>
<script type="text/javascript" async="async" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="TACdoxy.css" rel="stylesheet" type="text/css">
<!-- -->
<script type="text/javascript" src="TAC_navtree_hacks.js"></script>
</head>
<body>
<div style="background:#FFDDDD;font-size:120%;text-align:center;margin:0;padding:5px">Please, help us to better know about our user community by answering the following short survey: <a href="https://forms.gle/wpyrxWi18ox9Z5ae9">https://forms.gle/wpyrxWi18ox9Z5ae9</a></div>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td id="projectlogo"><img alt="Logo" src="TAC_Logo.png"/></td>
<td id="projectalign" style="padding-left: 0.5em;">
<div id="projectname"><a href="https://jvegh@bitbucket.org/jvegh/timeawarecomputingsimulator">TAC V0.0.4 @ 2021.03.25</a>
</div>
</td>
<td> <div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.17 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license-end */
</script>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
<div id="nav-tree">
<div id="nav-tree-contents">
<div id="nav-sync" class="sync"></div>
</div>
</div>
<div id="splitbar" style="-moz-user-select:none;"
class="ui-resizable-handle">
</div>
</div>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(document).ready(function(){initNavTree('TAC_BASIC_TECHNICAL_Addressing_PAGE.html',''); initResizable(); });
/* @license-end */
</script>
<div id="doc-content">
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
</div>
<div class="PageDoc"><div class="header">
<div class="headertitle">
<div class="title">BASIC module placing and addressing </div> </div>
</div><!--header-->
<div class="contents">
<div class="toc"><h3>Table of Contents</h3>
<ul><li class="level1"><a href="#TAC_BASIC_TECHNICAL_Addressing_Introduction">Introduction</a></li>
<li class="level1"><a href="#TAC_BASIC_TECHNICAL_Addressing_GROUPING">Module grouping</a><ul><li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_CLUSTER">The Hexagonal cluster</a></li>
<li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_ProxyModules">The proxy modules</a></li>
<li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_ClusterHead">The cluster head</a></li>
<li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_ClusterPhantom">The phantom clusters</a></li>
</ul>
</li>
<li class="level1"><a href="#TAC_BASIC_TECHNICAL_Addressing_LOGICAL">Module's hierarchic logical addressing</a><ul><li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_PHYSICAL">The physical address</a></li>
<li class="level2"><a href="#TAC_BASIC_TECHNICAL_Addressing_ClusterAddress">The cluster addressing</a></li>
</ul>
</li>
<li class="level1"><a href="#TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC">Hierarchic communication</a></li>
</ul>
</div>
<div class="textblock"><h1><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_Introduction"></a>
Introduction</h1>
<p>One of the bottlenecks in organizing cooperation between independently working electronic modules, that they not only must address each other, but also need to take care of all details of the communication, with special emphasis on synchronizing their operation. The module addressing and communication has been designed with effective cooperation of many modules in mind, as opposed to the individually efficient, but not cooperating and communicating, segregated processors, and letting the user's to take care of their cooperation, in the frames provided by the <a class="el" href="GLOSSARY.html#GLOSSARY_HW">HW</a> designers.</p>
<p>Given that this is a base package, it implements this signalling and communicating layer (called bottom layer), and prepares placekeepers (in form of general-purpose modules, with many utilities) in the top layer. The top layer functionality is implemented in the built-on-top modules.</p>
<h1><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_GROUPING"></a>
Module grouping</h1>
<p>During fabrication, the modules are placed in a 2-dimensional structure, i.e. they have natively X and Y <em>coordinates</em> and they can easily be arranged to form a one-dimensional vector, i.e. they can also have natively a <em>unique sequence number</em> (it is arranged column-wise). The grid points (<a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> units) are technologically arranged (and also by technologically: the even rows/columns are shifted by a half grid position). That is, a module can be referred to by a single index (scProcessor::ByID_Get(int ID)), a pair of indices (<a class="el" href="classscProcessor.html#a8d266318f3e788338b5b0c15870147ef" title="Get an scGridPoint by its indices.">scProcessor::ByIndex_Get(int X,int Y)</a>), and a pair of coordinates (scProcessor::ByPosition_Get(int XPos,int YPos)); they all refer to the same physical module.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_CLUSTER"></a>
The Hexagonal cluster</h2>
<p>This special (<a class="el" href="GLOSSARY.html#GLOSSARY_CNN">CNN</a>-like arrangement enables us to consider the rectangular grid (logically) as a hexagonal grid. We can also interpret different neighborship relations. The <em>first order neighbors</em> have a common boundary, the <em>second order neighbors</em> have a common neighbor. In order to avoid half numbers, in direction Y the numbers are increasing by two rather than one (that is, in direction Y the <em>position</em> and the <em>index</em> differ by a factor of two). The modules have a common boundary with all their immediate neighbors and can be addressed by using relative coordinates; for example, neighbor <em>NE</em> means the neighbor module of the actual point in direction north-east. </p><div class="fragment"><div class="line"> \ N(X,Y+2) /</div>
<div class="line"> ---------</div>
<div class="line">NW(X-1,Y+1) / \ NE(X+1,Y+1)</div>
<div class="line"> --------< (X,Y) >--------</div>
<div class="line">SW(X-1,Y-1) \ / SE(X+1,Y-1)</div>
<div class="line"> ---------</div>
<div class="line"> / S(X,Y-2)\</div>
</div><!-- fragment --><p>Also, the modules are organized to form functional clusters as shown in Figure <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#Fig_HexagonalCluster">Fig_HexagonalCluster</a>. The central module is called the <em>cluster head</em>, the others are the <em>cluster member</em>s. The position of the individual modules can be described with their relative position to their immediate neighbor (and maybe second neighbor), they have a <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_LOGICAL">special logical address</a>. In this way, a module may have different valid <em>relative addresses</em>, providing the advantage of having different paths when a message needs to reach them during routing.</p>
<p><a class="anchor" id="Fig_HexagonalCluster"></a></p><div class="image">
<img src="HexagonalCluster.png" alt="" width="300px"/>
<div class="caption">
Gridpoint as a hexagonal arrangement</div></div>
<p>As shown in Figure <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#Fig_Hexagona2">Fig_Hexagona2</a> (the coordinates X and Y correspond to that of the rectangular grid). The rectangular grid is described by an <a class="el" href="classAbstractTopology.html">AbstractTopology</a>, where a vector, and a two-dimensional vector stores the address of the <a class="el" href="classGridPoint.html" title="This class handles the topological information for the modules. Provides a lot of math-only utility f...">GridPoint</a> objects. Also, the cluster heads are stored in a special vector. Given those storage methods, the <a class="el" href="classGridPoint.html" title="This class handles the topological information for the modules. Provides a lot of math-only utility f...">GridPoint</a> objects can be reached through different addressing methods, although the different addressing methods refer to the same physical module.</p>
<p>Notice that the common boundaries enable a special method of communication, <em>direct wiring</em>, which is the lowest level of the <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC">Hierarchic communication</a>. The blueish boxes are a special two-way communication unit (scIGPCB: the inter-gridpoint communication block), which enables a register-like communication between the direct neighbors.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_ProxyModules"></a>
The proxy modules</h2>
<p>The arrangement provides one more advantage. The direct wired scIGPCB blocks enable a (because of the direct wiring, economic) way of using proxy cores for messages. Any of the modules can serve as a proxy communication station for its neigbors. The special addressing mode <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_LOGICAL">Module's hierarchic logical addressing</a> enables to provide also a proxy address (it must be a first-order neighbor of the real target module), enabling to attach (denied or orphaned) modules to a "foreign" module.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_ClusterHead"></a>
The cluster head</h2>
<p>From addressing point of view, the head is a cluster member with in-cluster index ClusterNeighbor::cm_Head (zero) and of course has ClusterStatus::cs_Head. From architectural point of view, the cluster head is somewhat different from the simple members: they are 'fat' in the sense that they have two further elements. They have access to the inter-cluster bus (scClusterBus), which represents the next level of the <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC">Hierarchic communication</a>. The cluster heads (any only the heads) have access (wiring) to the memory system (M) and they serve as a gateway (G) to the higher-level <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC">Hierarchic communication</a>, the inter-processor bus (presently not implemented). The rest of cluster members is not wired to those external world; they must request their cluster head to proxy that functionality.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_ClusterPhantom"></a>
The phantom clusters</h2>
<p>Of course, a rectangular area cannot be covered with hexagonals without difficulties. As Figure <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#Fig_Hexagona2">Fig_Hexagona2</a> displays, there are incomplete clusters (where the cluster head exists but some of its first-order members are not implemented) and there are phantom clusters with orphan members: the member is physically implemented, but has no physical cluster head module (just a logical core: a phantom). The orphan cores are joined to one of the neighboring clusters during fabrication: they simply have a predefined proxy, so they can be used as a full-value <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a>; the only difference that in their address the <a class="el" href="structClusterAddress__t.html#acf14e4884465281332f182b26498e9ba" title="Reachable through this neighbor (Relative to the core)">ClusterAddress_t::Proxy</a> field is not zero.</p>
<p><a class="anchor" id="Fig_Hexagona2"></a></p><div class="image">
<img src="Hexagona2.png" alt="" width="500px"/>
<div class="caption">
The hexagonal arrangement of the gridpoints</div></div>
<h1><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_LOGICAL"></a>
Module's hierarchic logical addressing</h1>
<p>One of the key factors of scalability of computer networks is the sub-networking, i.e. communicating nodes are organized in a way that the communication takes place, as much as possible, within the subnetwork and only the part that targets other sub-network uses the higher level buses. The other key factor is that "the communication-to-computation ratio" is not much worse for the higher-level communication than that for the communication within the sub-network: the networking minimizes the number of "hops" needed to reach the destination.</p>
<p><a class="anchor" id="Fig_ClusterAddressing"></a></p><div class="image">
<img src="ClusterAddressing.png" alt="" width="500px"/>
<div class="caption">
The addressing mode used for hierarchic communication</div></div>
<p>The cluster address is composed akin to the subnetworks of the computer networks. A cluster is composed of 1+6 gridpoints, leaving space for a "broadcast" type message, too.</p>
<p>The address of an <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> (otherwise <a class="el" href="classGridPoint.html" title="This class handles the topological information for the modules. Provides a lot of math-only utility f...">GridPoint</a> #2) is given throughout this booklet as </p><div class="fragment"><div class="line">{0,0}=(7.H)</div>
<div class="line">{0,4}=(7.N:N)</div>
</div><!-- fragment --><p> where {Xpos,Ypos} are the <em>topological position</em> of the <a class="el" href="classGridPoint.html" title="This class handles the topological information for the modules. Provides a lot of math-only utility f...">GridPoint</a> and (Cluster.Member:Proxy) are the logical (cluster) address. The {Xpos,Ypos} coordinates enable to locate the <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> for the user on Figure <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#Fig_Hexagona2">Fig_Hexagona2</a>, and (Cluster.Member:Proxy) form enables the routing to deliver the message to its destination. Notice that proxy is not used in most of the cases; in such cases the default ':Proxy' is not displayed.</p>
<p>That is: {0,0} is the head of cluster 7; {0,4} is the north neighbor of the north member of cluster 7. Notice that some nodes have neighbors from a different cluster, so they might have two valid addresses: one with proxy using a foreign cluster head and one as ordinary element with their own proxy. This facility provides redumdanca and extraordinary facilitities on traffic organization. Say, </p><div class="fragment"><div class="line">{0,4}=(2.SW:NW)</div>
<div class="line">{0,4}=(2.NW:SW)</div>
</div><!-- fragment --><p> are also avalid access path to reach node </p><div class="fragment"><div class="line">{0,0}=(7.H)</div>
</div><!-- fragment --><p>This addressing gives way to <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC">Hierarchic communication</a>.</p>
<p>Given that the central elements (with orange color) have physically distinguished role, the usual way of addressing is to provide <a class="el" href="TAC_BASIC_TECHNICAL_Addressing_PAGE.html#TAC_BASIC_TECHNICAL_Addressing_ClusterHead">The cluster head</a> in the address.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_PHYSICAL"></a>
The physical address</h2>
<p>The mentioned physical addresses can be used referring to an element of a vector or a matrix of the modules, but they must somehow be mapped to the network connecting them, also needing additional protocols.</p>
<h2><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_ClusterAddress"></a>
The cluster addressing</h2>
<p>Similarly to computer networking, <em>any</em> of the native IDs can be used to address the <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> modules. The logical addressing is based on the <a class="el" href="structClusterAddress__t.html" title="A GridPoint can be addressed also by its cluster address of type ClusterAddress_t....">ClusterAddress_t</a> address that enables the set of the <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> modules to deliver the messages to their destination in the bottom layer of the <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> modules. In the present version only one <a class="el" href="classscProcessor.html" title="Implements a module-name alias facility (i.e., user-provided names. Given that the basic units is scH...">scProcessor</a> is assumed and used, but the addressing can be trivially extended to higher order modules (such as cards, racks, etc.) The only requirement is to distinguish one of the cluster heads, processors, etc. that has access to the higher level communication bus, and the message is automagically forwarded to any <a class="el" href="classscGridPoint.html" title="This class implements the autonomous grid point functionality: it is a communicating GridPoint....">scGridPoint</a> in the system. Presently <a class="el" href="structClusterAddress__t.html" title="A GridPoint can be addressed also by its cluster address of type ClusterAddress_t....">ClusterAddress_t</a> is assumed to have 32 bits.</p>
<h1><a class="anchor" id="TAC_BASIC_TECHNICAL_Addressing_HIERARCHIC"></a>
Hierarchic communication</h1>
</div></div><!-- contents -->
</div><!-- PageDoc -->
</div><!-- doc-content -->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
<ul>
<li class="footer">Generated on Sat Apr 3 2021 00:58:24 for TAC V0.0.4 @ 2021.03.25 by
<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.8.17 </li>
</ul>
</div>
</body>
</html>