Hardware and Software Co-design: An Architecture Proposal for a Network-on-Chip Switch based on Bufferless Data Flow
Read
2736
Timeswas read the article
729
Total PDF
2007
Total HTML
Share statistics
array:22 [ "pii" => "S1665642314716153" "issn" => "16656423" "doi" => "10.1016/S1665-6423(14)71615-3" "estado" => "S300" "fechaPublicacion" => "2014-02-01" "aid" => "71615" "copyright" => "Universidad Nacional Autónoma de México" "copyrightAnyo" => "2014" "documento" => "article" "licencia" => "http://creativecommons.org/licenses/by-nc-nd/4.0/" "subdocumento" => "fla" "cita" => "Journal of Applied Research and Technology. 2014;12:153-63" "abierto" => array:3 [ "ES" => true "ES2" => true "LATM" => true ] "gratuito" => true "lecturas" => array:2 [ "total" => 958 "formatos" => array:3 [ "EPUB" => 33 "HTML" => 586 "PDF" => 339 ] ] "itemAnterior" => array:18 [ "pii" => "S1665642314716141" "issn" => "16656423" "doi" => "10.1016/S1665-6423(14)71614-1" "estado" => "S300" "fechaPublicacion" => "2014-02-01" "aid" => "71614" "copyright" => "Universidad Nacional Autónoma de México" "documento" => "article" "licencia" => "http://creativecommons.org/licenses/by-nc-nd/4.0/" "subdocumento" => "fla" "cita" => "Journal of Applied Research and Technology. 2014;12:145-52" "abierto" => array:3 [ "ES" => true "ES2" => true "LATM" => true ] "gratuito" => true "lecturas" => array:2 [ "total" => 1013 "formatos" => array:3 [ "EPUB" => 41 "HTML" => 663 "PDF" => 309 ] ] "en" => array:11 [ "idiomaDefecto" => true "titulo" => "PSO-GA Based Optimized Feature Selection Using Facial and Clothing Information for Gender Classification" "tienePdf" => "en" "tieneTextoCompleto" => "en" "tieneResumen" => "en" "paginas" => array:1 [ 0 => array:2 [ "paginaInicial" => "145" "paginaFinal" => "152" ] ] "contieneResumen" => array:1 [ "en" => true ] "contieneTextoCompleto" => array:1 [ "en" => true ] "contienePdf" => array:1 [ "en" => true ] "resumenGrafico" => array:2 [ "original" => 0 "multimedia" => array:7 [ "identificador" => "fig0045" "etiqueta" => "Figure 9" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr9.jpeg" "Alto" => 461 "Ancho" => 907 "Tamanyo" => 49984 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0045" class="elsevierStyleSimplePara elsevierViewall">Classification accuracy of face and cloths fused features</p>" ] ] ] "autores" => array:1 [ 0 => array:2 [ "autoresLista" => "M. Nazir, A. Majid-Mirza, S. Ali-Khan" "autores" => array:3 [ 0 => array:2 [ "nombre" => "M." "apellidos" => "Nazir" ] 1 => array:2 [ "nombre" => "A." "apellidos" => "Majid-Mirza" ] 2 => array:2 [ "nombre" => "S." "apellidos" => "Ali-Khan" ] ] ] ] ] "idiomaDefecto" => "en" "EPUB" => "https://multimedia.elsevier.es/PublicationsMultimediaV1/item/epub/S1665642314716141?idApp=UINPBA00004N" "url" => "/16656423/0000001200000001/v2_201505081640/S1665642314716141/v2_201505081640/en/main.assets" ] "en" => array:16 [ "idiomaDefecto" => true "titulo" => "Hardware and Software Co-design: An Architecture Proposal for a Network-on-Chip Switch based on Bufferless Data Flow" "tieneTextoCompleto" => true "paginas" => array:1 [ 0 => array:2 [ "paginaInicial" => "153" "paginaFinal" => "163" ] ] "autores" => array:1 [ 0 => array:3 [ "autoresLista" => "S. Ortega-Cisneros, H.J. Cabrera-Villaseñor, J.J. Raygoza-Panduro, F. Sandoval, R. Loo-Yau" "autores" => array:5 [ 0 => array:4 [ "nombre" => "S." "apellidos" => "Ortega-Cisneros" "email" => array:1 [ 0 => "sortega@gdl.cinvestav.mx" ] "referencia" => array:1 [ 0 => array:2 [ "etiqueta" => "<span class="elsevierStyleSup">1</span>" "identificador" => "aff0005" ] ] ] 1 => array:3 [ "nombre" => "H.J." "apellidos" => "Cabrera-Villaseñor" "referencia" => array:1 [ 0 => array:2 [ "etiqueta" => "<span class="elsevierStyleSup">1</span>" "identificador" => "aff0005" ] ] ] 2 => array:3 [ "nombre" => "J.J." "apellidos" => "Raygoza-Panduro" "referencia" => array:1 [ 0 => array:2 [ "etiqueta" => "<span class="elsevierStyleSup">2</span>" "identificador" => "aff0010" ] ] ] 3 => array:3 [ "nombre" => "F." "apellidos" => "Sandoval" "referencia" => array:1 [ 0 => array:2 [ "etiqueta" => "<span class="elsevierStyleSup">1</span>" "identificador" => "aff0005" ] ] ] 4 => array:3 [ "nombre" => "R." "apellidos" => "Loo-Yau" "referencia" => array:1 [ 0 => array:2 [ "etiqueta" => "<span class="elsevierStyleSup">1</span>" "identificador" => "aff0005" ] ] ] ] "afiliaciones" => array:2 [ 0 => array:3 [ "entidad" => "Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional Unidad Guadalajara Guadalajara, Jalisco, México" "etiqueta" => "1" "identificador" => "aff0005" ] 1 => array:3 [ "entidad" => "Centro Universitario de Ciencias Exactas e Ingenierías Universidad de Guadalajara Guadalajara, Jalisco, México" "etiqueta" => "2" "identificador" => "aff0010" ] ] ] ] "resumenGrafico" => array:2 [ "original" => 0 "multimedia" => array:7 [ "identificador" => "fig0030" "etiqueta" => "Figure 6" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr6.jpeg" "Alto" => 753 "Ancho" => 841 "Tamanyo" => 117843 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0030" class="elsevierStyleSimplePara elsevierViewall">Complete block diagram for the network switch. Although the communication path seems to be made of simple multiplexors and demultiplexors, they have been customized to work directly with the control signals from the allocators</p>" ] ] ] "textoCompleto" => """ <span class="elsevierStyleSections"><span id="sec0005" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">1</span><span class="elsevierStyleSectionTitle" id="sect0020">Introduction</span><p id="par0005" class="elsevierStylePara elsevierViewall">Network on-Chip (NoC) is an emerging technology for interconnecting functional blocks in a digital system consisting of multiple processing units. The concept of NoC [<a class="elsevierStyleCrossRef" href="#bib0005">1</a>, <a class="elsevierStyleCrossRef" href="#bib0035">7</a>, <a class="elsevierStyleCrossRef" href="#bib0040">8</a>] has attracted interest in academia and in the development of commercial applications <a class="elsevierStyleCrossRef" href="#bib0045">[9]</a>. However, even with multiple research teams working on new developments, the NoC interconnect structures have not reached a technical maturity for emerging as the communication infrastructure that gives solution to the challenges present in modern digital systems.</p><p id="par0010" class="elsevierStylePara elsevierViewall">A Network-on-Chip is the adaptation of the concept of computer networks applied within an integrated circuit. The network concept from computer science includes the interconnection of computers or network resources that could be mass storage units (NAS or SAN), firewalls, or dedicated servers; all of them sharing information through the network infrastructure, made of routers, switches, or bridges. The performance of a computer network is defined by its topology, the method of controlling data flow <a name="p154"></a>and the strategy used to guide the information through the network.</p><p id="par0015" class="elsevierStylePara elsevierViewall">To ground these concepts in silicon, it is necessary to tailor the experience in the area of computer networks to a more restricted environment, such as an integrated circuit. In an integrated circuit, the processing elements are represented by IP blocks, general purpose processors, or memory elements.</p><p id="par0020" class="elsevierStylePara elsevierViewall">The interconnection infrastructure can be reduced to routers or switches, given the limited area in which the digital system may extend, and the transmission medium is composed of metal lines inside the integrated circuit. The network performance is proportional to the amount of information that moves between its members and the time that the communication channels are active.</p></span><span id="sec0010" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">2</span><span class="elsevierStyleSectionTitle" id="sect0025">Related Work</span><p id="par0025" class="elsevierStylePara elsevierViewall">Some previous work in the area of on-chip networks that are worth mentioning are the following: PNOC <a class="elsevierStyleCrossRef" href="#bib0010">[2]</a>, this work was develop for reconfigurable devices. PNOC implements two different kinds of network switches, one for single processing units that can communicate inside a small group of same, known as processing island, and another for a message passing between different islands. CUNOC <a class="elsevierStyleCrossRef" href="#bib0050">[10]</a> is an on-chip network with a data flow control based on package switching, because CUNOC uses a mesh topology, there must be two flavors of switches: one for the edges of the network and another for the central area. SoCWire <a class="elsevierStyleCrossRef" href="#bib0055">[11]</a> is an on-chip network developed with the objective of being compatible with the SpaceWire data transfer protocol <a class="elsevierStyleCrossRef" href="#bib0060">[12]</a>. This protocol is currently in use on missions of the European Space Agency. Star- Wheels <a class="elsevierStyleCrossRef" href="#bib0065">[13]</a>, this network has a foray into the new “wheel” topology, which is very similar to Spidergon topology <a class="elsevierStyleCrossRef" href="#bib0020">[4]</a> but with the difference of implementing a “super” network switch in the center of the communication infrastructure. For a wider survey on on-chip networks, refer to <a class="elsevierStyleCrossRef" href="#bib0070">[14]</a>.</p></span><span id="sec0015" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">3</span><span class="elsevierStyleSectionTitle" id="sect0030">Hardware Description of the Network Switch</span><p id="par0030" class="elsevierStylePara elsevierViewall">The architectural design of the network switch was made keeping in mind that the module was aimed to be simple and lightweight. Because of these objectives, we needed a topology that promoted these characteristics. We chose Spidergon as the topology to be targeted because it is regular and symmetrical; these two characteristics mean that the network would look the same from any point of the net; and therefore, all the switches would be the same.</p><p id="par0035" class="elsevierStylePara elsevierViewall">In addition, a Spidergon switch does not have a complete connection between all its communication channels, but rather it only provides links between input/output ports as shown in <a class="elsevierStyleCrossRef" href="#fig0005">Figure 1</a>. For example, the right communication channel, from a Spidergon switch, can only manage data transfers between it and the left channel and the processing unit channel. A Thorough analysis of the properties of the Spidergon topology fall outside of the scope of this document, but a comprehensive treatise can be found in <a class="elsevierStyleCrossRef" href="#bib0050">[10]</a>.</p><elsevierMultimedia ident="fig0005"></elsevierMultimedia><p id="par0040" class="elsevierStylePara elsevierViewall">Since the selected goal was the optimization of the logical resources needed to deploy one switch, a connection-oriented philosophy for controlling data flow between switches was chosen. This philosophy is known as circuit switching, and it reduces the number of storage elements needed to handle the transactions of information between switches. The reduction of storage elements takes place because, before every data transaction occurs, there must be a physical connection between the source and the destination. Once the connection is made, the data will flow as if there were a hard link between the two nodes, and temporary storage for message forwarding will not be necessary.<a name="p155"></a></p><span id="sec0020" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">3.1</span><span class="elsevierStyleSectionTitle" id="sect0035">Network Switch: Operation</span><p id="par0045" class="elsevierStylePara elsevierViewall">Broadly speaking, the relationship between network switches during a data transfer operation occurs as follows: Suppose the proposed network is as illustrated in <a class="elsevierStyleCrossRef" href="#fig0010">Figure 2</a>. The transaction starts when there is a need to transmit information between the nodes “02” and “07” of the network. A node is defined by a set of one switch and its processing element; however, all the communication services are provided exclusively by the switch. The path to follow to reach the destination node requires an intermediate hop on node “06”, so that node “02” sends a request for the exclusive use of the output port that connects node “06” to node “07”, as <a class="elsevierStyleCrossRef" href="#fig0010">Figure 2</a> (a) shows.</p><elsevierMultimedia ident="fig0010"></elsevierMultimedia><p id="par0050" class="elsevierStylePara elsevierViewall">Node number “06” shall now evaluate the petition received and determine whether the requested output port is available for assignment or not. In the case of a successful allocation by node “06”, the request sent from node “02” is transmitted transparently in the direction of the destination node, in this case node number “07”. After this operation, node “06” has already completed its arbitration tasks, hence it is limited to transmit the information received in its input port connected to node “02” to its output port connected to node “07” (This operation does not block the work of arbitration and allocation of the other ports that are not affected by communication between nodes “02” and “07”).</p><p id="par0055" class="elsevierStylePara elsevierViewall">As opposed to the former case, the transaction flow between nodes may not be completed because some resources are not available. Our network switch is designed to handle this kind of situations as show in <a class="elsevierStyleCrossRef" href="#fig0010">Figure 2</a> (c, d), where a data link between node “05” and node “07” is desired. In this second situation, the way to reach the destination node is by performing a jump through node “06”, which is already handling a link between node “02” and node “07”; nevertheless, the knowledge of pre-existing connections is not available for each network switch, therefore node “05” sends a request through its output port toward node “07”, and this request must make a stop in node “06”. Node “06” receives the request, but it determines that the requested port is currently in use, hence it generates a reject signal towards node “05”. After node “05” gets the reject signal, it may opt to keep the request and wait for it to be resolved satisfactorily, or it can, as in this example, momentarily withdraw its request and make another attempt after a period of time established by the processing unit.</p></span><span id="sec0025" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">3.2</span><span class="elsevierStyleSectionTitle" id="sect0040">Network Switch: Internals</span><p id="par0060" class="elsevierStylePara elsevierViewall">The switch includes four communication channels, each of which is formed by two transmission ports: a port dedicated to data logging, and a port for sending data out of the switch. At the microarchitectural level, each output port is connected to some of the input ports from the other communication channels.<a name="p156"></a></p><p id="par0065" class="elsevierStylePara elsevierViewall">The signals on each input port can be classified into control signals and data signals. The control signals are shown in <a class="elsevierStyleCrossRef" href="#fig0015">Figure 3</a>; they are used during the formation and destruction of a link between switches. During an operation of data transmission, the control signals do not have an active role on the switch. The data signals are used during the establishment of a link as carriers of the address of the destination node; after that, they serve as medium to move data packages between nodes.</p><elsevierMultimedia ident="fig0015"></elsevierMultimedia><p id="par0070" class="elsevierStylePara elsevierViewall">The control signals are used at three stages in the switch, these stages are responsible for implementing a policy of “decode - arbitrate - retain”. The first stage is implemented by a distributor module, shown in <a class="elsevierStyleCrossRef" href="#fig0020">Figure 4</a>, whose main task is sending all the signals entering the switch through an input port towards the correct output port, which eventually will lead the target node.</p><elsevierMultimedia ident="fig0020"></elsevierMultimedia><p id="par0075" class="elsevierStylePara elsevierViewall">The mechanism used by the distributor to select which output port is the objective of the request is made from a comparator and a retainer; at this point, the destination address, which is carried by the data signals, is compared with the address of the current node. If the addresses are equal, it would mean that the current node is the final destination of the request, therefore, all signals are routed toward the output port of the processing element channel. Otherwise, the request will continue in the same direction from where it enters the switch, i.e., if entered by the left channel, the signal will abandon the switch through the right channel. As can be noticed, the switch does not have the ability to change the trajectory of the requests, which means simpler control logic.</p><p id="par0080" class="elsevierStylePara elsevierViewall">The propagator module is in charge of passing the results of an arbitration process. In other words, it will let us know if a link has been successfully formed ahead or if the request has been rejected.</p><p id="par0085" class="elsevierStylePara elsevierViewall">The next stage inside the switch is carried out by the allocator. There is an allocator per output port and its task is to choose which request will have exclusive access to the output port. As shown in <a class="elsevierStyleCrossRef" href="#fig0025">Figure 5</a>, the allocator is fed by the distributors. The arbiter-retainer module asks the priority generator which distributor will have the highest priority for the current arbitration process. The priority generator is a hardware implementation of the round-robin algorithm, meaning that the priority rotates among all entrances to the allocator, always giving lowest priority to the winner of the last resource arbitration process.</p><elsevierMultimedia ident="fig0025"></elsevierMultimedia><p id="par0090" class="elsevierStylePara elsevierViewall">The retention stage affects both the distributor and the allocator that were involved in the last successful arbitration process. When the allocator selects a winner, the path between the distributor and the allocator, needs to be locked, so that all data arriving through the input port of the distributor may go directly to the output port of the allocator. This link must not have any meta-states while a release signal (release_in) does not arrive to the allocator.</p><p id="par0095" class="elsevierStylePara elsevierViewall">Finally, there is the need to interconnect the distributors with their respective allocators; this connection is done by the transport logic, which consists of an arrangement of customized multiplexors and demultiplexors, designed to interact directly with the control signals from the allocators. <a class="elsevierStyleCrossRef" href="#fig0030">Figure 6</a> shows the relationship between all the modules from the switch.</p><elsevierMultimedia ident="fig0030"></elsevierMultimedia><p id="par0100" class="elsevierStylePara elsevierViewall">To complete all the stages inside a switch, one clock cycle is needed; for that reason, the default <a name="p157"></a>latency between two nodes is equal to the number of hops between them. The inverse process of tearing down a link between two nodes also takes one clock cycle per switch to be completed; however, once a switch has received the tear down signal, it is ready to establish a different link at the next clock cycle.</p></span></span><span id="sec0030" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">4</span><span class="elsevierStyleSectionTitle" id="sect0045">Switch Simulator</span><p id="par0105" class="elsevierStylePara elsevierViewall">As part of the development flow of our switch, we made a network simulator. The principal role of the simulator was to provide a framework where we can test different combination of values for the switch parameters; for example, we can generate an estimate of performance for a network made of 16 switches, once we get the estimate, we can change the number of data lines between nodes and resimulate the network to know how these changes affect the performance.</p><p id="par0110" class="elsevierStylePara elsevierViewall">The simulator was designed under an object- oriented paradigm [<a class="elsevierStyleCrossRef" href="#bib0025">5</a>, <a class="elsevierStyleCrossRef" href="#bib0030">6</a>]. The data infrastructure was modeled by means of 3 classes; one that represents the network switches in a true bit and cycle manner, a generator class that is responsible for imitating the operations that a processing element normally would do. The generator class is one of the most important factors in the simulator because it determines when to start a request for communication, how often the request is released, to whom the request is directed, the size of the information packages, how to set the release signal once a communication is over and handling the network contentions. This class was modeled by means of a finite state machine shown in <a class="elsevierStyleCrossRef" href="#fig0035">Figure 7</a>.</p><elsevierMultimedia ident="fig0035"></elsevierMultimedia><p id="par0115" class="elsevierStylePara elsevierViewall">Finally, a ‘Net’ class is used as a container for all the pairs “generator - switch.” Besides a container, the net class gives orders to every element about what needs to be done to carry out the simulation, and to register all events going on in the simulated network. In <a class="elsevierStyleCrossRef" href="#fig0040">Figure 8</a>, we provide a class diagram of all the members of the simulator, as well their methods and attributes.<a name="p158"></a></p><elsevierMultimedia ident="fig0040"></elsevierMultimedia><span id="sec0035" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">4.1</span><span class="elsevierStyleSectionTitle" id="sect0050">The Switch Class</span><p id="par0120" class="elsevierStylePara elsevierViewall">This class describes all the behaviors and internal states from a hardware switch; for example, control and data signals are represented as boolean attributes. All the attributes are grouped by the input/output port to which they belong, and all the attributes that serve as communication points between instances of the switch class are made public.</p><p id="par0125" class="elsevierStylePara elsevierViewall">The Switch class uses 8 methods to imitate the behavior of the hardware module, all these methods are shown in <a class="elsevierStyleCrossRef" href="#fig0040">figure 8</a> and are used for tasks such as setting the initial values for the attributes that will be used in the simulation.</p><p id="par0130" class="elsevierStylePara elsevierViewall">A brief description of what happens during a simulation cycle inside each switch instance is as follows: The update switch method is the interface with the other classes and is in charge of calling all the subsequent methods to complete a simulation cycle. The first task that must be done is executing the _update_rqs() method, this method works like a positive edge of a clock signal, when this method is called, all the values from the attributes representing the output ports from the neighbors switches are copied to the attributes representing the input ports of the instance that called the method; all the values obtained in this way are used by the _update_\n <direction>\n _port() routines that implement all the work that would be normally carried out by the allocators. Before a request is selected by the latter methods, the priority for the arbitration process must be updated by the _update_priority() routine that implements the round-robin algorithm.\n </direction></p></span><span id="sec0040" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">4.2</span><span class="elsevierStyleSectionTitle" id="sect0055">The Switch Class</span><p id="par0135" class="elsevierStylePara elsevierViewall">The generator instances are paired with the switch objects to form a network node in the simulator. This class sends all the stimuli that a processing element would send to the networks switch. Broadly speaking, the generator can divide its functions in transmission and reception operations, and the transmissions going out the node are managed by the FSM shown in <a class="elsevierStyleCrossRef" href="#fig0035">Figure 7</a>. Nevertheless, it is worth noting that the routing decisions are made within the method _routing(). This method selects the traffic pattern that will be used by the node during the entire simulation. Each generator instance can select different traffic patterns by sending the correct parameters to the _routing() method. In order to add new patterns to this routine, the user must introduce the code with the new algorithm to select the valid targets nodes for communications going out of this node. A code snippet of the _routing() method is shown.<span class="elsevierStyleDisplayedQuote" id="dsq0005"><p id="spar0100" class="elsevierStyleSimplePara elsevierViewall">if traffic == 1:</p><p id="spar0105" class="elsevierStyleSimplePara elsevierViewall"><span class="elsevierStyleHsp" style=""></span>while True:</p><p id="spar0110" class="elsevierStyleSimplePara elsevierViewall"><span class="elsevierStyleHsp" style=""></span>Self.out_port[‘addr_out’] = random.randrange /</p><p id="spar0115" class="elsevierStyleSimplePara elsevierViewall"><span class="elsevierStyleHsp" style=""></span>(1, self._out_status[‘total_nodos’]+1)</p><p id="spar0120" class="elsevierStyleSimplePara elsevierViewall"><span class="elsevierStyleHsp" style=""></span>if self.out_port[‘add_out’] != self._addr_my:</p><p id="spar0125" class="elsevierStyleSimplePara elsevierViewall"><span class="elsevierStyleHsp" style=""></span>break</p></span></p><p id="par0140" class="elsevierStylePara elsevierViewall">The reception operation is limited to generate control signals to acknowledge the acceptance of incoming requests. Once a request has arrived to a generator in idle state, the finite state machine shown in <a class="elsevierStyleCrossRef" href="#fig0045">Figure 9</a>, releases the cts signal to let the source of the request know that it is clear to receive data packages. Once the number of simulation cycles necessary for the finalization of the transmission of the data have taken place, the _fsm_rx() routine, which implements the reception operations, sends a release signal to every switch object in the communication path to let them know that the transmission of data is over and the resources assigned must be deallocated.</p><elsevierMultimedia ident="fig0045"></elsevierMultimedia></span><span id="sec0045" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">4.3</span><span class="elsevierStyleSectionTitle" id="sect0060">The Net Class</span><p id="par0145" class="elsevierStylePara elsevierViewall">The timing, for the execution of all actions needed to complete a simulation cycle, is provided by the net class. First, it receives the parameters to configure the simulation. The user provides these parameters by means of a command line interface that contains the number of nodes, number of cycles that the simulation will last, the size of packages, number of data lines between nodes, how often the nodes will release a request and the traffic pattern for each node.<a name="p159"></a></p><p id="par0150" class="elsevierStylePara elsevierViewall">Once the information is in possession of a net object, it starts to create instances of switch and generator classes. The configuration parameters for each created object are passed by the _deploy_net() method, and these parameters are used by the _init_() routines of each object for their initialization. After the simulated network has been initialized, a cyclic series of steps are executed starting with the _clock_edge() routine. This routine will trigger an update of the attributes representing the input ports of each switch object. The next step has as its goal the execution of all arbitration processes on each switch object and the evaluation of the finite state machine on every generator instance; this step is executed by the _sim_tick() routine.</p><p id="par0155" class="elsevierStylePara elsevierViewall">At this point, all the processes regarding the functional units of the network have been executed; hence, the final step is to register the internal state of each network switch and generator called. This action is performed by the _observer_log(). This method has access to all the internal state attributes of the generator and switch instances; thus, it will create log files as the one shown in <a class="elsevierStyleCrossRef" href="#fig0050">Figure 10</a> for each network node on the network. All the steps above are repeated once for each simulation cycle requested by the user.</p><elsevierMultimedia ident="fig0050"></elsevierMultimedia></span><span id="sec0050" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">4.4</span><span class="elsevierStyleSectionTitle" id="sect0065">Synthetic Workloads</span><p id="par0160" class="elsevierStylePara elsevierViewall">Workloads are one of the most important elements in the simulations of on chip networks. The workload represents the test data to be released on the simulated network; this data represents requests for data transmissions. A workload planned too lightly can result in slanted performance profiles, showing only the best or the worse behavior of the network.</p><p id="par0165" class="elsevierStylePara elsevierViewall">For this work, we used synthetic workloads to simulate possible scenarios in a digital system. The flexibility of the use of synthetic loads lies in the possibility of varying the traffic pattern, the addresses to which each network switch can communicate, and the frequency with which each node releases a communication request to the network. For example, a random workload will allow each node in the network to be a possible target for a communication, while a restricted workload could only allow communications to nodes numbered “05”, “03” and “07”.</p></span></span><span id="sec0055" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">5</span><span class="elsevierStyleSectionTitle" id="sect0070">Results</span><p id="par0170" class="elsevierStylePara elsevierViewall">All results presented in this paper used the next setup: the switch was implemented in a Virtex 4 - xc4vlx100-11ff1513, using the synthesis tool provided by the manufacturer. The performance results were obtained using the simulator developed specifically for this network.</p><span id="sec0060" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">5.1</span><span class="elsevierStyleSectionTitle" id="sect0075">Synthetic Workloads</span><p id="par0175" class="elsevierStylePara elsevierViewall">A detailed look at the logic resources occupied by every single internal component of the switch, as shown in <a class="elsevierStyleCrossRef" href="#fig0055">Figure 11</a>, lets us know that the critical path of combinational delays is going to be inside the allocators.</p><elsevierMultimedia ident="fig0055"></elsevierMultimedia><p id="par0180" class="elsevierStylePara elsevierViewall">These results about occupied area should not vary in a drastic way, thanks to the decoupling between the control and data signals.</p><p id="par0185" class="elsevierStylePara elsevierViewall">For the correct characterization of the switch performance, we synthesized 4 different switches with a different number of lines for the data transaction between them. <a class="elsevierStyleCrossRef" href="#fig0060">Figure 12</a> shows the occupation for each switch model. It is worth noting that the increment in the width of de data lines has influence on the occupation because of <a name="p160"></a>the relation between the data signals and the distributors of the switch; each distributor requires us to compare the address of the destination node and its address. This operation infers a comparator with a width equal to the number of data signals, as they carry the destination address. The average percent of extra resources needed to increase the number of data lines is around 43.33% between switch models.</p><elsevierMultimedia ident="fig0060"></elsevierMultimedia><p id="par0190" class="elsevierStylePara elsevierViewall">The most affected resources are the flip-flops from the FPGA, as they are needed in each input and output of the switch to provide a synchronous operation. It is not possible to use BRAMs because of the distributed nature of the communications channels of the switch: therefore, they are implemented using the logic element of the FPGA. As a maximum operation frequency we obtained 238.66<span class="elsevierStyleHsp" style=""></span>MHz for the 32 data lines model of the switch. All other models results can be consulted in <a class="elsevierStyleCrossRef" href="#fig0060">Figure 12</a>.</p></span><span id="sec0065" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">5.2</span><span class="elsevierStyleSectionTitle" id="sect0080">Simulation Results</span><p id="par0195" class="elsevierStylePara elsevierViewall">We developed three scenarios with the following characteristics in common: Each network was composed of 16 nodes. We let the simulations run for 25,000 clock cycles, and the information transactions consisted of packages of 256 bytes. The results presented in this section are the average from running a single scenario ten times; this methodology was used to mitigate the presence of best/worst case for the simulation.</p><p id="par0200" class="elsevierStylePara elsevierViewall">In particular, the first scenario interconnecting each network node, with data links of 8 bits wide, uses activation periods of between 10% and 90%. The latter refers to the probability that each node would like to start a data transaction when it is in idle, and finally the traffic pattern is random, so each node can select as a valid target all other nodes of the network. The simulator generates logs with the behavior of each node of the network. The following data are found in these logs: at which clock cycle a node generated a request, the answers to its requests, how much time it spent waiting to restart the request for a link after a reject signal, the time spent simulating an internal processing in the node, and how many cycles it was inactive.</p><p id="par0205" class="elsevierStylePara elsevierViewall"><a class="elsevierStyleCrossRef" href="#fig0065">Figure 13</a> shows a summary of the log generated for node number 15 in one simulation from scenario 1. In particular, this node presented an activation pattern of 90%; hence, each time it was able, it requested communication with another node.</p><elsevierMultimedia ident="fig0065"></elsevierMultimedia><p id="par0210" class="elsevierStylePara elsevierViewall">One of the most important parameters to measure in network is the latency or average time that would take to complete a satisfactory link between two nodes of the network. This parameter is highly volatile as it is affected by the current traffic on the network, for example, if just a few nodes are transmitting data then there would be a few paths occupied so there would not be the need to wait for “resource contentions”. As latency itself is not a reliable measure, we use a relation between the latency and the number of already established paths around the network. Using this relation we can evaluate the average latency of different on-chip networks, even if they use different topologies or data-flow controls. In <a class="elsevierStyleCrossRef" href="#fig0070">Figure 14</a>, we present the average latency presented in a single switch and only for 1 simulation run under scenario 2, which consists of a network formed by 16 nodes with 16-bit data links in width, activation patterns between 10% and 90%, and a random traffic pattern. As we can see, when 10 of the 16 nodes are trying to establish a connection, the network was capable of handling 9 of the connection requests satisfactorily. For global results we present the average latency of all nodes of the network from the ten runs of each scenario as shown in <a class="elsevierStyleCrossRef" href="#fig0080">Figure 16</a> (a).<a name="p161"></a></p><elsevierMultimedia ident="fig0070"></elsevierMultimedia><p id="par0215" class="elsevierStylePara elsevierViewall">Another key parameter to evaluate a network on-chip, and therefore their switches, is the average performance, which we can think of as the number of connections between nodes that can hold the network simultaneously, in contrast with the total number of attended and unattended requests that are around the network.</p><p id="par0220" class="elsevierStylePara elsevierViewall">For example, <a class="elsevierStyleCrossRef" href="#fig0075">Figure 15</a> shows the average performance of one node during 10 simulations under scenario 3, which consists of a network formed by 16 nodes with 8-bit width data links, activation patterns of 100%, and a restricted traffic pattern. The performance results for the simulation of 10 runs of each scenario are presented in <a class="elsevierStyleCrossRef" href="#fig0080">Figure 16</a> (b).</p><elsevierMultimedia ident="fig0075"></elsevierMultimedia><elsevierMultimedia ident="fig0080"></elsevierMultimedia></span></span><span id="sec0070" class="elsevierStyleSection elsevierViewall"><span class="elsevierStyleLabel">6</span><span class="elsevierStyleSectionTitle" id="sect0085">Conclusions</span><p id="par0225" class="elsevierStylePara elsevierViewall">In this paper we present the description of a novel architecture for a network switch, involving a circuit switching technique, targeted to networks with a Spidergon topology. As a result, the necessary logic elements for the deployment of the network infrastructure are reduced to a minimum. In addition to the light weight architecture, the switch offers warranties once a path between 2 nodes has formed, as in-order data arrival.</p><p id="par0230" class="elsevierStylePara elsevierViewall">It is worth noting from <a class="elsevierStyleCrossRef" href="#fig0060">Figure 12</a> that the best balance between logic resource consumption and operation frequency is delivered by the implementation of the switch with 16-bit width data ports. In addition to the latter, this switch model can form NoCs with an ideal bandwidth of 2.29<span class="elsevierStyleHsp" style=""></span>Mb/Seg in their bisection. The smallest switch of the family presents 8 lines for data transactions. This small module can find a place even on small FPGA devices. As an example of this, a network formed by 16 of these switch needs only 3.648% of the Virtex 4 device.</p><p id="par0235" class="elsevierStylePara elsevierViewall">To have a better perspective of our small factor switch, <a class="elsevierStyleCrossRef" href="#fig0085">Figure 17</a> shows a contrast between the switches proposed in: CoNoChi<a class="elsevierStyleCrossRef" href="#bib0075">[15]</a>, CuNoC<a class="elsevierStyleCrossRef" href="#bib0050">[10]</a>, DyNoC<a class="elsevierStyleCrossRef" href="#bib0080">[16]</a>, PNoC<a class="elsevierStyleCrossRef" href="#bib0010">[2]</a>, QuarC<a class="elsevierStyleCrossRef" href="#bib0085">[17]</a>, RMBoC<a class="elsevierStyleCrossRef" href="#bib0015">[3]</a> and SoCWire<a class="elsevierStyleCrossRef" href="#bib0055">[11]</a>. It is easy to see that our module with 32 data lines has the lowest resource requirements; however, it is worth noting that the switches presented in the other works have added more characteristics to their design such as error handling, quality of service and reliability enhancements.</p><elsevierMultimedia ident="fig0085"></elsevierMultimedia><p id="par0240" class="elsevierStylePara elsevierViewall">In the absence of a network simulator, the profiling of the switch performance on an on-chip network, under different stress levels, would have been a <a name="p162"></a>more time-consuming task because of the time needed to design hardware modules that would play the role of processing elements, and as a consequence, we would have had to use a limited number of scenarios for the profiling.</p><p id="par0245" class="elsevierStylePara elsevierViewall">In regards to the average latency, shown in <a class="elsevierStyleCrossRef" href="#fig0080">Figure 16</a> (a), we can notice that it remains under 300 clock cycles, even with a high number of requests around the network. However, it is worth noting that the use of a restricted traffic pattern, as in scenario number 3, improves the average latency even more than incrementing the number of data lines connecting each node with its neighbors. If the traffic pattern is previously known for a system, the right way to improve the latency will be to locate IPs with heavy communication necessities near each other; nevertheless, this is not always possible, thus the increase of the number of data lines will be an acceptable choice but with a logical resource penalty.</p><p id="par0250" class="elsevierStylePara elsevierViewall">As for the performance, a network formed with the switches presented in this paper can handle satisfactorily up to 5 simultaneous requests; after this number, the requests start to collide into each other. This resource contention is independent from the model of the switch selected for the network. The ineffectiveness of incrementing the number of data lines is shown in <a class="elsevierStyleCrossRef" href="#fig0080">Figure 16</a> (b) on the results between scenario 2 and scenario 3. However, the analysis of the performance for the scenario 3, which uses a restricted traffic pattern, shows that the use of smart planned traffic patterns can improve significantly the performance of the network. In this particular case the network in scenario 3 was able of handling an average of 11 requests at a maximum workload on the network.</p><p id="par0255" class="elsevierStylePara elsevierViewall">An average from the 3 scenarios gives us an idea of what we can expect from the network under unknown circumstances; for example, we can see that the maximum performance that it can achieve is 57%, i.e., handling 9 links simultaneously between network nodes. However, if all members of the network make a simultaneous request, the performance will drop inevitably below 31.25%.</p><p id="par0260" class="elsevierStylePara elsevierViewall">All results lead us to conclude that a network, with our switch, will provide a good solution for communications, inside on-chip digital systems with highly restricted logic elements. We also note that the simulator proved to be a valuable tool for evaluating the impact that some design options have before synthesis.</p></span></span> """ "textoCompletoSecciones" => array:1 [ "secciones" => array:11 [ 0 => array:3 [ "identificador" => "xres498804" "titulo" => "Abstract" "secciones" => array:1 [ 0 => array:1 [ "identificador" => "abst0005" ] ] ] 1 => array:2 [ "identificador" => "xpalclavsec520323" "titulo" => "Keywords" ] 2 => array:3 [ "identificador" => "xres498805" "titulo" => "Resumen" "secciones" => array:1 [ 0 => array:1 [ "identificador" => "abst0010" ] ] ] 3 => array:2 [ "identificador" => "sec0005" "titulo" => "Introduction" ] 4 => array:2 [ "identificador" => "sec0010" "titulo" => "Related Work" ] 5 => array:3 [ "identificador" => "sec0015" "titulo" => "Hardware Description of the Network Switch" "secciones" => array:2 [ 0 => array:2 [ "identificador" => "sec0020" "titulo" => "Network Switch: Operation" ] 1 => array:2 [ "identificador" => "sec0025" "titulo" => "Network Switch: Internals" ] ] ] 6 => array:3 [ "identificador" => "sec0030" "titulo" => "Switch Simulator" "secciones" => array:4 [ 0 => array:2 [ "identificador" => "sec0035" "titulo" => "The Switch Class" ] 1 => array:2 [ "identificador" => "sec0040" "titulo" => "The Switch Class" ] 2 => array:2 [ "identificador" => "sec0045" "titulo" => "The Net Class" ] 3 => array:2 [ "identificador" => "sec0050" "titulo" => "Synthetic Workloads" ] ] ] 7 => array:3 [ "identificador" => "sec0055" "titulo" => "Results" "secciones" => array:2 [ 0 => array:2 [ "identificador" => "sec0060" "titulo" => "Synthetic Workloads" ] 1 => array:2 [ "identificador" => "sec0065" "titulo" => "Simulation Results" ] ] ] 8 => array:2 [ "identificador" => "sec0070" "titulo" => "Conclusions" ] 9 => array:2 [ "identificador" => "xack161141" "titulo" => "Acknowledgements" ] 10 => array:1 [ "titulo" => "References" ] ] ] "pdfFichero" => "main.pdf" "tienePdf" => true "PalabrasClave" => array:1 [ "en" => array:1 [ 0 => array:4 [ "clase" => "keyword" "titulo" => "Keywords" "identificador" => "xpalclavsec520323" "palabras" => array:6 [ 0 => "NoC" 1 => "SoC" 2 => "FPGA" 3 => "RTL" 4 => "simulator" 5 => "hardware software co-design" ] ] ] ] "tieneResumen" => true "resumen" => array:2 [ "en" => array:2 [ "titulo" => "Abstract" "resumen" => "<span id="abst0005" class="elsevierStyleSection elsevierViewall"><p id="spar0090" class="elsevierStyleSimplePara elsevierViewall">The use of on chip networks as interconnection media for systems implemented in FPGAs is limited by the amount of logical resources necessary to deploy the network in the target device, and the time necessary to adjust the network parameters to achieve the performance goal for the system. In this paper we present a switch architecture, with data flow control based on circuit switching and aimed for on-chip networks with a Spidergon topology, which seeks to reduce the area occupied without severely affecting the overall network performance. As a result, we obtained a switch that requires only 114 slices in its most economic version on a Virtex 4-device. We also provide a performance profile, obtained by subjecting a network formed by these switches to different synthetic workloads within a simulator. This simulator was developed as part of the design flow of the switch, and it proves to be an essential tool for the test and validation process.</p></span>" ] "es" => array:2 [ "titulo" => "Resumen" "resumen" => "<span id="abst0010" class="elsevierStyleSection elsevierViewall"><p id="spar0095" class="elsevierStyleSimplePara elsevierViewall">El uso de redes en chip como medio de interconexión para sistemas digitales implementados en FPGA se encuentra limitado por la cantidad de recursos lógicos necesarios para implementar la infraestructura de red dentro del dispositivo, además del tiempo necesario para el ajuste de características de la red para obtener las metas de desempeño requeridas por el sistema. En este documento presentamos una arquitectura para conmutadores de red en chip, con control de flujo de datos basado en conmutación de circuitos, desarrollada con el objetivo de formar redes de topología Spidergon, y buscando reducir el área necesaria para su implementación sin castigar sobremanera el desempeño de la red. Como resultado de nuestro trabajo presentamos un conmutador que requiere solamente 114 slices de un dispositivo Virtex 4, en su versión más económica. Además proveemos de un perfil de desempeño de una red formada por nuestros conmutadores dentro de un simulador a medida. Este simulador fue desarrollado como parte del flujo de diseño del conmutador y demostró ser una herramienta esencial para la prueba y la validación del módulo.</p></span>" ] ] "multimedia" => array:17 [ 0 => array:7 [ "identificador" => "fig0005" "etiqueta" => "Figure 1" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr1.jpeg" "Alto" => 677 "Ancho" => 852 "Tamanyo" => 84310 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0005" class="elsevierStyleSimplePara elsevierViewall">Possible connections from (a) processing element, (b) diagonal, (c) left, and (d) right channels</p>" ] ] 1 => array:7 [ "identificador" => "fig0010" "etiqueta" => "Figure 2" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr2.jpeg" "Alto" => 754 "Ancho" => 863 "Tamanyo" => 103637 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0010" class="elsevierStyleSimplePara elsevierViewall">(a, b) A link is formed between node 02 and 07. (c, d) In this case, node 06 is already handling a connection, thus it denies the request from 05</p>" ] ] 2 => array:7 [ "identificador" => "fig0015" "etiqueta" => "Figure 3" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr3.jpeg" "Alto" => 699 "Ancho" => 939 "Tamanyo" => 108718 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0015" class="elsevierStyleSimplePara elsevierViewall">The dotted line represents all control signals of the switch, while solid lines represent the data lines</p>" ] ] 3 => array:7 [ "identificador" => "fig0020" "etiqueta" => "Figure 4" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr4.jpeg" "Alto" => 343 "Ancho" => 927 "Tamanyo" => 53580 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0020" class="elsevierStyleSimplePara elsevierViewall">The distributor for one of the output ports, the diagonal and processing element distributors need to connect to an extra allocator since they can form a link with the diagonal opposed switch and the processing element of the node, respectively</p>" ] ] 4 => array:7 [ "identificador" => "fig0025" "etiqueta" => "Figure 5" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr5.jpeg" "Alto" => 370 "Ancho" => 872 "Tamanyo" => 62817 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0025" class="elsevierStyleSimplePara elsevierViewall">Block diagram for the allocator module</p>" ] ] 5 => array:7 [ "identificador" => "fig0030" "etiqueta" => "Figure 6" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr6.jpeg" "Alto" => 753 "Ancho" => 841 "Tamanyo" => 117843 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0030" class="elsevierStyleSimplePara elsevierViewall">Complete block diagram for the network switch. Although the communication path seems to be made of simple multiplexors and demultiplexors, they have been customized to work directly with the control signals from the allocators</p>" ] ] 6 => array:7 [ "identificador" => "fig0035" "etiqueta" => "Figure 7" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr7.jpeg" "Alto" => 425 "Ancho" => 919 "Tamanyo" => 63130 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0035" class="elsevierStyleSimplePara elsevierViewall">Finite state machine controlling the requests from a node</p>" ] ] 7 => array:7 [ "identificador" => "fig0040" "etiqueta" => "Figure 8" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr8.jpeg" "Alto" => 916 "Ancho" => 912 "Tamanyo" => 139378 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0040" class="elsevierStyleSimplePara elsevierViewall">Class diagram for the network simulator</p>" ] ] 8 => array:7 [ "identificador" => "fig0045" "etiqueta" => "Figure 9" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr9.jpeg" "Alto" => 372 "Ancho" => 821 "Tamanyo" => 55010 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0045" class="elsevierStyleSimplePara elsevierViewall">Finite State Machine controlling all the requests incoming to a node</p>" ] ] 9 => array:7 [ "identificador" => "fig0050" "etiqueta" => "Figure 10" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr10.jpeg" "Alto" => 316 "Ancho" => 876 "Tamanyo" => 50824 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0050" class="elsevierStyleSimplePara elsevierViewall">Log file created by the _observer_log() method. One of these files is created for each node</p>" ] ] 10 => array:7 [ "identificador" => "fig0055" "etiqueta" => "Figure 11" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr11.jpeg" "Alto" => 502 "Ancho" => 820 "Tamanyo" => 67690 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0055" class="elsevierStyleSimplePara elsevierViewall">Logical elements needed to deploy each module which forms a network switch</p>" ] ] 11 => array:7 [ "identificador" => "fig0060" "etiqueta" => "Figure 12" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr12.jpeg" "Alto" => 338 "Ancho" => 830 "Tamanyo" => 42634 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0060" class="elsevierStyleSimplePara elsevierViewall">Switch occupation in slices, maximum operating frequency and percentage occupied on a Virtex 4 device</p>" ] ] 12 => array:7 [ "identificador" => "fig0065" "etiqueta" => "Figure 13" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr13.jpeg" "Alto" => 349 "Ancho" => 819 "Tamanyo" => 52975 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0065" class="elsevierStyleSimplePara elsevierViewall">A high percentage in “waiting for restart” reflects a network under a heavy traffic</p>" ] ] 13 => array:7 [ "identificador" => "fig0070" "etiqueta" => "Figure 14" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr14.jpeg" "Alto" => 328 "Ancho" => 819 "Tamanyo" => 45802 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0070" class="elsevierStyleSimplePara elsevierViewall">Average latency for one switch; “spikes” like the one in “9 requests”, are removed, repeating 10 times each scenario</p>" ] ] 14 => array:7 [ "identificador" => "fig0075" "etiqueta" => "Figure 15" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr15.jpeg" "Alto" => 328 "Ancho" => 819 "Tamanyo" => 49209 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0075" class="elsevierStyleSimplePara elsevierViewall">Average performance presented under scenario 3, the minimum performance represents the worst performance</p>" ] ] 15 => array:7 [ "identificador" => "fig0080" "etiqueta" => "Figure 16" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr16.jpeg" "Alto" => 961 "Ancho" => 819 "Tamanyo" => 96785 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0080" class="elsevierStyleSimplePara elsevierViewall">(a) Average latency, (b) average Performance</p>" ] ] 16 => array:7 [ "identificador" => "fig0085" "etiqueta" => "Figure 17" "tipo" => "MULTIMEDIAFIGURA" "mostrarFloat" => true "mostrarDisplay" => false "figura" => array:1 [ 0 => array:4 [ "imagen" => "gr17.jpeg" "Alto" => 339 "Ancho" => 830 "Tamanyo" => 45316 ] ] "descripcion" => array:1 [ "en" => "<p id="spar0085" class="elsevierStyleSimplePara elsevierViewall">Difference between logical resources necessary for our switch and other works in the area</p>" ] ] ] "bibliografia" => array:2 [ "titulo" => "References" "seccion" => array:1 [ 0 => array:2 [ "identificador" => "bibs0005" "bibliografiaReferencia" => array:17 [ 0 => array:3 [ "identificador" => "bib0005" "etiqueta" => "[1]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "The future of wires" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:3 [ 0 => "R. Ho" 1 => "K.W. Mai" 2 => "M.A. Horowitz" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "Revista" => array:5 [ "tituloSerie" => "Proceedings of the IEEE" "fecha" => "2001" "volumen" => "89" "paginaInicial" => "490" "paginaFinal" => "504" ] ] ] ] ] ] 1 => array:3 [ "identificador" => "bib0010" "etiqueta" => "[2]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "PNoC: a flexible circuit- switched NoC for FPGA-based systems" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:2 [ 0 => "C. Hilton" 1 => "B. Nelson" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "Revista" => array:5 [ "tituloSerie" => "Computers and Digital Techniques, IEE Proceedings -" "fecha" => "2006" "volumen" => "153" "paginaInicial" => "181" "paginaFinal" => "188" ] ] ] ] ] ] 2 => array:3 [ "identificador" => "bib0015" "etiqueta" => "[3]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Dynamic interconnection of reconfigurable modules on reconfigurable devices" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:2 [ 0 => "C. Bobda" 1 => "A. Ahmadinia" ] ] ] ] ] "host" => array:1 [ 0 => array:2 [ "doi" => "10.1016/j.archoralbio.2015.03.007" "Revista" => array:6 [ "tituloSerie" => "Design & Test of Computers, IEEE" "fecha" => "2005" "volumen" => "22" "paginaInicial" => "443" "paginaFinal" => "451" "link" => array:1 [ 0 => array:2 [ "url" => "https://www.ncbi.nlm.nih.gov/pubmed/25951616" "web" => "Medline" ] ] ] ] ] ] ] ] 3 => array:3 [ "identificador" => "bib0020" "etiqueta" => "[4]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:1 [ "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:5 [ 0 => "M. Coppola" 1 => "M.D. Grammatikakis" 2 => "R. Locatelli" 3 => "G. Maruccia" 4 => "L. Pieralisi" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "Libro" => array:3 [ "titulo" => "Design of Cost-Efficient Interconnect Processing Units: Spidergon STNoC" "fecha" => "2008" "editorial" => "CRC Press, Inc" ] ] ] ] ] ] 4 => array:3 [ "identificador" => "bib0025" "etiqueta" => "[5]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:1 [ "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:1 [ 0 => "M. Lutz" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "Libro" => array:3 [ "titulo" => "Learning Python: Powerful Object-Oriented Programming" "fecha" => "2009" "editorial" => "O'Reilly Media, Inc" ] ] ] ] ] ] 5 => array:3 [ "identificador" => "bib0030" "etiqueta" => "[6]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:1 [ "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:1 [ 0 => "M. Weisfeld" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "Libro" => array:3 [ "titulo" => "The Object-Oriented Thought Process" "fecha" => "2000" "editorial" => "Sams" ] ] ] ] ] ] 6 => array:3 [ "identificador" => "bib0035" "etiqueta" => "[7]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Route packets, not wires: on-chip interconnection networks" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:2 [ 0 => "W.J. Dally" 1 => "B. Towles" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:4 [ "paginaInicial" => "684" "paginaFinal" => "689" "conferencia" => "Design Automation Conference" "serieFecha" => "2001" ] ] ] ] ] ] 7 => array:3 [ "identificador" => "bib0040" "etiqueta" => "[8]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Network-on-chip: the intelligence is in the wire" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:2 [ 0 => "G. Mas" 1 => "P. Martin" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Computer Design: VLSI in Computers and Processors" "paginaInicial" => "174" "paginaFinal" => "177" "conferencia" => "IEEE International Conference on" "serieFecha" => "2004" ] ] ] ] ] ] 8 => array:3 [ "identificador" => "bib0045" "etiqueta" => "[9]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "The 48-core SCC Processor: the Programmer's View" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:12 [ 0 => "T.G. Mattson" 1 => "R.F. Van der Wijngaart" 2 => "M. Riepen" 3 => "T. Lehnig" 4 => "P. Brett" 5 => "W. Haas" 6 => "P. Kennedy" 7 => "J. Howard" 8 => "S. Vangal" 9 => "N. Borkar" 10 => "G. Ruhl" 11 => "S. Dighe" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "High Performance Computing, Networking, Storage and Analysis (SC)" "paginaInicial" => "1" "paginaFinal" => "11" "conferencia" => "2010 International Conference for" "serieFecha" => "2010" ] ] ] ] ] ] 9 => array:3 [ "identificador" => "bib0050" "etiqueta" => "[10]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "CuNoC: A Scalable Dynamic NoC for Dynamically Reconfigurable FPGAs" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:4 [ 0 => "S. Jovanovic" 1 => "C. Tanougast" 2 => "S. Weber" 3 => "C. Bobda" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Field Programmable Logic and Applications" "paginaInicial" => "753" "paginaFinal" => "756" "conferencia" => "International Conference on" "serieFecha" => "2007" ] ] ] ] ] ] 10 => array:3 [ "identificador" => "bib0055" "etiqueta" => "[11]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "SoCWire: A Network-on-Chip Approach for Reconfigurable System-on-Chip Designs in Space Applications" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:4 [ 0 => "B. Osterloh" 1 => "H. Michalik" 2 => "B. Fiethe" 3 => "K. Kotarowski" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Adaptive Hardware and Systems" "paginaInicial" => "51" "paginaFinal" => "56" "conferencia" => "NASA/ESA Conference on" "serieFecha" => "2008" ] ] ] ] ] ] 11 => array:3 [ "identificador" => "bib0060" "etiqueta" => "[12]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "SpaceWire: a spacecraft onboard network for real-time communications" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:2 [ 0 => "S.M. Parkes" 1 => "P. Armbruster" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:4 [ "paginaInicial" => "6" "paginaFinal" => "10" "conferencia" => "Real Time Conference" "serieFecha" => "2005" ] ] ] ] ] ] 12 => array:3 [ "identificador" => "bib0065" "etiqueta" => "[13]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Star- Wheels Network-on-Chip featuring a self-adaptive mixed topology and a synergy of a circuit - and a packet-switching communication protocol" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:4 [ 0 => "D. Gohringer" 1 => "L. Bin" 2 => "M. Hubner" 3 => "J. Becker" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Field Programmable Logic and Applications" "paginaInicial" => "320" "paginaFinal" => "325" "conferencia" => "International Conference on" "serieFecha" => "2009" ] ] ] ] ] ] 13 => array:3 [ "identificador" => "bib0070" "etiqueta" => "[14]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Networks-on-Chip: Challenges, trends and mechanisms for enhancements" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:1 [ 0 => "O. Tayan" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Information and Communication Technologies" "paginaInicial" => "57" "paginaFinal" => "62" "conferencia" => "International Conference on" "serieFecha" => "2009" ] ] ] ] ] ] 14 => array:3 [ "identificador" => "bib0075" "etiqueta" => "[15]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Applying Partial Reconfiguration to Networks-On-Chips" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:3 [ 0 => "T. Pionteck" 1 => "R. Koch" 2 => "C. Albrecht" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Field Programmable Logic and Applications" "paginaInicial" => "1" "paginaFinal" => "6" "conferencia" => "International Conference on" "serieFecha" => "2006" ] ] ] ] ] ] 15 => array:3 [ "identificador" => "bib0080" "etiqueta" => "[16]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "DyNoC: A dynamic infrastructure for communication in dynamically reconfugurable devices" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:6 [ 0 => "C. Bobda" 1 => "A. Ahmadinia" 2 => "M. Majer" 3 => "J. Teich" 4 => "S. Fekete" 5 => "J. van der Veen" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Field Programmable Logic and Applications" "paginaInicial" => "153" "paginaFinal" => "158" "conferencia" => "International Conference on" "serieFecha" => "2005" ] ] ] ] ] ] 16 => array:3 [ "identificador" => "bib0085" "etiqueta" => "[17]" "referencia" => array:1 [ 0 => array:2 [ "contribucion" => array:1 [ 0 => array:2 [ "titulo" => "Quarc: A Novel Network-On-Chip Architecture" "autores" => array:1 [ 0 => array:2 [ "etal" => false "autores" => array:3 [ 0 => "M. Moadeli" 1 => "W. Vanderbauwhede" 2 => "A. Shahrabi" ] ] ] ] ] "host" => array:1 [ 0 => array:1 [ "LibroEditado" => array:5 [ "titulo" => "Parallel and Distributed Systems" "paginaInicial" => "705" "paginaFinal" => "712" "conferencia" => "14th IEEE International Conference on" "serieFecha" => "2008" ] ] ] ] ] ] ] ] ] ] "agradecimientos" => array:1 [ 0 => array:4 [ "identificador" => "xack161141" "titulo" => "Acknowledgements" "texto" => "<p id="par0265" class="elsevierStylePara elsevierViewall">Heading: left justified, in 9-point Arial italics bold font, in sentence-case.</p> <p id="par0270" class="elsevierStylePara elsevierViewall">Content: All text must be in a two-column format. Columns are to be 8<span class="elsevierStyleHsp" style=""></span>cm wide with a .59<span class="elsevierStyleHsp" style=""></span>cm space between them. Also, it must be fully justified, single-spaced, in 9-point Arial regular font.</p>" "vista" => "all" ] ] ] "idiomaDefecto" => "en" "url" => "/16656423/0000001200000001/v2_201505081640/S1665642314716153/v2_201505081640/en/main.assets" "Apartado" => null "PDF" => "https://static.elsevier.es/multimedia/16656423/0000001200000001/v2_201505081640/S1665642314716153/v2_201505081640/en/main.pdf?idApp=UINPBA00004N&text.app=https://www.elsevier.es/" "EPUB" => "https://multimedia.elsevier.es/PublicationsMultimediaV1/item/epub/S1665642314716153?idApp=UINPBA00004N" ]
| Year/Month | Html | Total | |
|---|---|---|---|
| 2024 October | 28 | 4 | 32 |
| 2024 September | 26 | 5 | 31 |
| 2024 August | 25 | 4 | 29 |
| 2024 July | 25 | 3 | 28 |
| 2024 June | 28 | 4 | 32 |
| 2024 May | 28 | 6 | 34 |
| 2024 April | 31 | 2 | 33 |
| 2024 March | 32 | 3 | 35 |
| 2024 February | 31 | 4 | 35 |
| 2024 January | 14 | 2 | 16 |
| 2023 December | 23 | 8 | 31 |
| 2023 November | 19 | 4 | 23 |
| 2023 October | 20 | 13 | 33 |
| 2023 September | 13 | 2 | 15 |
| 2023 August | 11 | 3 | 14 |
| 2023 July | 7 | 7 | 14 |
| 2023 June | 11 | 0 | 11 |
| 2023 May | 17 | 10 | 27 |
| 2023 April | 32 | 4 | 36 |
| 2023 March | 56 | 3 | 59 |
| 2023 February | 22 | 7 | 29 |
| 2023 January | 11 | 2 | 13 |
| 2022 December | 16 | 14 | 30 |
| 2022 November | 33 | 4 | 37 |
| 2022 October | 35 | 9 | 44 |
| 2022 September | 29 | 12 | 41 |
| 2022 August | 50 | 9 | 59 |
| 2022 July | 33 | 10 | 43 |
| 2022 June | 24 | 8 | 32 |
| 2022 May | 48 | 12 | 60 |
| 2022 April | 33 | 10 | 43 |
| 2022 March | 32 | 10 | 42 |
| 2022 February | 24 | 7 | 31 |
| 2022 January | 38 | 7 | 45 |
| 2021 December | 11 | 12 | 23 |
| 2021 November | 15 | 8 | 23 |
| 2021 October | 21 | 11 | 32 |
| 2021 September | 28 | 13 | 41 |
| 2021 August | 27 | 10 | 37 |
| 2021 July | 26 | 7 | 33 |
| 2021 June | 14 | 6 | 20 |
| 2021 May | 19 | 8 | 27 |
| 2021 April | 59 | 13 | 72 |
| 2021 March | 42 | 7 | 49 |
| 2021 February | 21 | 9 | 30 |
| 2021 January | 23 | 10 | 33 |
| 2020 December | 18 | 5 | 23 |
| 2020 November | 33 | 12 | 45 |
| 2020 October | 15 | 16 | 31 |
| 2020 September | 23 | 6 | 29 |
| 2020 August | 18 | 3 | 21 |
| 2020 July | 21 | 6 | 27 |
| 2020 June | 14 | 5 | 19 |
| 2020 May | 20 | 3 | 23 |
| 2020 April | 13 | 1 | 14 |
| 2020 March | 28 | 6 | 34 |
| 2020 February | 20 | 4 | 24 |
| 2020 January | 26 | 5 | 31 |
| 2019 December | 28 | 6 | 34 |
| 2019 November | 23 | 6 | 29 |
| 2019 October | 18 | 1 | 19 |
| 2019 September | 20 | 4 | 24 |
| 2019 August | 12 | 3 | 15 |
| 2019 July | 15 | 5 | 20 |
| 2019 June | 24 | 14 | 38 |
| 2019 May | 60 | 45 | 105 |
| 2019 April | 59 | 22 | 81 |
| 2019 March | 31 | 1 | 32 |
| 2019 February | 3 | 5 | 8 |
| 2019 January | 7 | 2 | 9 |
| 2018 December | 0 | 2 | 2 |
| 2018 November | 3 | 2 | 5 |
| 2018 October | 5 | 8 | 13 |
| 2018 September | 17 | 6 | 23 |
| 2018 August | 4 | 9 | 13 |
| 2018 July | 2 | 1 | 3 |
| 2018 June | 6 | 1 | 7 |
| 2018 May | 3 | 10 | 13 |
| 2018 April | 2 | 2 | 4 |
| 2018 March | 1 | 0 | 1 |
| 2018 February | 1 | 1 | 2 |
| 2018 January | 5 | 2 | 7 |
| 2017 December | 2 | 0 | 2 |
| 2017 November | 10 | 0 | 10 |
| 2017 October | 3 | 3 | 6 |
| 2017 September | 8 | 3 | 11 |
| 2017 August | 6 | 3 | 9 |
| 2017 July | 7 | 0 | 7 |
| 2017 June | 9 | 21 | 30 |
| 2017 May | 11 | 13 | 24 |
| 2017 April | 11 | 21 | 32 |
| 2017 March | 8 | 23 | 31 |
| 2017 February | 6 | 10 | 16 |
| 2017 January | 3 | 1 | 4 |
| 2016 December | 9 | 4 | 13 |
| 2016 November | 8 | 3 | 11 |
| 2016 October | 9 | 5 | 14 |
| 2016 September | 9 | 5 | 14 |
| 2016 August | 7 | 3 | 10 |
| 2016 July | 3 | 1 | 4 |
| 2016 June | 5 | 12 | 17 |
| 2016 May | 2 | 2 | 4 |
| 2016 April | 6 | 7 | 13 |
| 2016 March | 6 | 4 | 10 |
| 2016 February | 3 | 7 | 10 |
| 2016 January | 8 | 5 | 13 |
| 2015 December | 5 | 4 | 9 |
| 2015 November | 6 | 2 | 8 |
| 2015 October | 7 | 4 | 11 |
| 2015 September | 10 | 2 | 12 |
| 2015 August | 2 | 2 | 4 |
| 2015 July | 3 | 1 | 4 |
| 2015 June | 1 | 0 | 1 |
| 2015 May | 3 | 0 | 3 |
| 2015 April | 2 | 2 | 4 |
Show all