Professional Documents
Culture Documents
Noc Architecture
Noc Architecture
Architecture
This chapter describes the architecture of a RECONNECT router and its
configurations. Multiple configuration parameters provide an easy way to
alter the behavior and functionality of RECONNECT by either changing values
of constants (configuration flexibility) or by replacing modules (module
flexibility). The effects of some of the parameters are not only restricted
to RECONNECT or the Fabric, but also depend on other modules of the
architecture in which the Fabric is integrated into. Since this architecture
is not known at the time of writing, it is henceforth referred to as target
architecture.
3.1 Architectural Overview of the Router
The task a router has to fulfill, can be easily described: Take the data from
the incoming Input Port (IP), check which direction it needs to be forwarded
to, and pass it on to the next router. A more detailed description is depicted
in figure 3.1.
Collection Data from
neighboring IPs
Crossbar Traversal IP/OP Arbitration
Relative Address
Update
VC Selection for Storage
VC Arbitration
Route Calculation
next Router previous Router
Storing of incoming Flit in VC
Figure 3.1: The processing steps a flit encounters while traversing a router.
1. The incoming data is stored in one of the Virtual Channel (VC). The VC
has been calculated by the routing algorithm in the previous router. It is
important to note that the VC cannot be chosen arbitrarily as described
are described. From section 3.3 onwards a point of view of the flit is taken
and the modules which a router consists of, are described in detail as it
traverses through the router.
3.2 Configuration Parameters
This section describes the constants (`defines mentioned in ./trunk/includes/define.bsv) which are evaluated by the Bluespec System Verilog
(BSV) precompiler. With corresponding `ifdef and `else branches the
precompiler removes paths which are never executed. However in some cases
such as the evaluation of the number of flits a packet comprises of, the value
of a defined constant cannot be calculated during the time of precompilation
3.2 Configuration Parameters 19
and the if-else branches are not removed. In the next compilation step the
following Bluespec compiler evaluates static variables and removes the part
of the branch that is never true.
3.2.1 DEBUG_NOC[1-3]
If one of the DEBUG_NOC is defined, the routers will print out debugging
messages during simulation. This is achieved by the $display command.
Obviously it is only relevant during simulations and does not have an equivalent
component in hardware. The higher the number of this define, the more
messages are printed. During simulations printing messages has a serious
impact on the performance. Hence the system designer can speed up the
execution time by disabling and commenting out messages which are of no
interest.
3.2.2 ASMUNIT_DEBUG
Similar to DEBUG_NOC[1-3] this define is used to print out debugging messages
for the Assembly Unit (AU) (refer to section 3.3.1). This along with
the provided test bench is particular useful, to check, if the conversion from
the union representing different packet types, into the bit structure of flits
and back, has been implemented correctly. One of the major cause of bugs
and errors is the miscalculation of the bit field sizes of the structures within
However this might lead to packets whose flits got interleaved. The
destination is currently not able to distinguish flits belonging to different
packets. Secondly the buffer sizes required for virtual cut-through
will be in an order of magnitude larger compared to wormhole routing
[17].
If MULTIFLITSUPPORT is set, the format of the flit is converted into a
union that provides header, headtail, payload and tail flits. Headtail flits are
used, if the header provides some bits for payload and the whole payload
of the packet fits into it. If MULTIFLITSUPPORT is not set, all packets become
headtail flits and hence the union becomes superfluous.
In theory and for later requirements this mechanism of binding IP/OP
pairs could be exploited to provide virtual circuits between a source and
destination, since the channel is never terminated as long as no tail flit is
sent.