Architecture of the TCP/IP CoreThis project is aimed at developing the full TCP/IP protocol as an open-source IP core which can be freely used, as well as to develop know-how on protocol boosting for complex protocols such as TCP/IP. The problem was quite challenging, especially if we consider that just about all commercial implementations of TCP/IP do not fully implement all of the protocol specifications. Figure 1. TCP/IP IP Core ArchitectureA block diagram of the architecture of the TCP/IP core is shown in Figure 1. There is a MII interface towards the Ethernet network. On the user (or application) side there is a software-like interface, i.e. there are VHDL modules corresponding directly to the software library routines, e.g. to establish a connection. The MII interface is fully compliant in terms of control signals with the IEEE 802.3 prototype. This architecture implements the TCP/IP protocol and also all the other protocols that are necessary for the TCP/IP in order to function in a real-life network. This means that protocols such as ARP, ICMP, UDP are also implemented. The architecture has the following subsystems: RxETHER checks whether the datagram destination is on the local implementation. ARP-RECV-REPLY and ICMP-RECV-REPLY are building replies for the corresponding protocols. The IP-RECV has to identify what type of packet is encapsulated in the IP datagram. The CRC-32 module computes the CRC of the incoming datagram. The TCP and the UDP are the modules that implement the corresponding high-level protocols. The ARP table is a memory for keeping the correspondences between IP and Physical Addresses. TxRAM is the basic component of architecture's "send" side, it is a 256 byte memory in which the datagram that is going to be transmitted is build step by step. First, the upper layer protocols (TCP, UDP) write their data, then the IP protocol by the module IP-SEND writes the IP header and last the Ethernet header is placed by the module ETHER-SEND. This component implements the LLC (Logical Link Control) sub layer. Finally the MAC sub layer is implemented by the TxETHER component. The CRC-32 component computes the CRC-32 while the data are transmitted towards the network and adds it to the end of the datagram. The ARP-REQUEST module creates an ARP Request datagram for a given IP address and transmits it over the network. The CONTROL component is the system's heart. It is responsible to synchronize all the modules during the reception of a datagram, and also supervises the access to the TxRAM by all the other components.The UDP module sends and receives UDP datagrams between multiple applications. In this architecture there is more attention given to the TCP protocol implementation, so the UDP component can maintain 15 simultaneous connections but this can easily change if we choose to use a larger memory. The UDP module is made of two FSMs, the "send" and the "receive" FSM. This means that parallelism is achieved between sending and receiving UDP packets. The UDP architecture has FIFOs in order to receiv...

Abstract. Partial reconfiguration (PR) of FPGAs can be used to dynamically extend and adapt the functionality of computing systems, swapping in and out HW tasks. To coordinate the on-demand task execution, we propose and implement a run time system manager for scheduling software (SW) tasks on available processor(s) and hardware (HW) tasks on any number of reconfigurable regions of a partially reconfigurable FPGA. Fed with the initial partitioning of the application into tasks, the corresponding task graph, and the available task mappings, the RTSM considers the runtime status of each task and region, e.g. busy, idle, scheduled for reconfiguration/execution etc., to execute tasks. Our RTSM supports task reuse and configuration prefetching to minimize reconfigurations, task movement among regions to efficiently manage the FPGA area, and RR reservation for future reconfiguration and execution. We validate its correctness using our RTSM to execute an image processing application on a ZedBoard platform. We also evaluate its features within a simulation framework, and find that despite the technology limitations, our approach can give promising results in terms of quality of scheduling. IntroductionReconfiguration can dynamically adapt the functionality of hardware systems by swapping in and out HW tasks. To select the proper resource for loading and triggering HW task reconfiguration and execution in partially reconfigurable systems with FPGAs, efficient and flexible runtime system support is needed [6]. In this paper we propose and implement a Run-Time System Manager (RTSM) incorporating efficient scheduling mechanisms that balance effectively the execution of HW and SW tasks and the use of physical resources. We aim to execute as fast as possible a given application, without exhausting the physical resources. Our motivation during the development of RTSM was to find ways to overcome the strict technology restrictions imposed by the Xilinx PR flow [8]:  Static partitioning of the reconfigurable surface in reconfigurable regions (RR).

No abstract

No abstract