US10282315B2

US10282315B2 - Software assisted hardware configuration for software defined network system-on-chip

Info

Publication number: US10282315B2
Application number: US14/672,006
Authority: US
Inventors: Nimalan Siva; Premshanth Theivendran; Kishore Badari Atreya
Original assignee: Cavium LLC
Current assignee: Cavium International; Marvell Asia Pte Ltd; Xpliant Inc
Priority date: 2015-03-27
Filing date: 2015-03-27
Publication date: 2019-05-07
Also published as: US20160283413A1

Abstract

A software and hardware co-validation for SDN SoC method and system are able to be used to test software and hardware using PCIe (or another implementation) utilizing sockets and messages as the communication medium. An entire software stack as well as hardware are able to be tested. Additionally, multiple chips (SoCs) are able to be programmed at the same time, not just one, as in previous implementations.

Description

FIELD OF INVENTION

The present invention relates to the field of networking.

BACKGROUND OF THE INVENTION

Software-defined networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. A system on a chip or System-on-Chip (SoC) is an integrated circuit (IC) that integrates all components of an electronic system into a single chip. It is possible to implement many networking features on a single chip using combinations of software and hardware.

BRIEF SUMMARY

A software and hardware co-validation for SDN SoC method and system are able to be used to test software and hardware using PCIe (or another implementation) utilizing sockets and messages as the communication medium.

In one aspect, a system comprises a software module, a hardware module and a Peripheral Component Interconnect express driver configured for communicating between the software module and the hardware module, wherein the Peripheral Component Interconnect express driver utilizes transmission control protocol packets for communicating and is embedded in a kernel of the system. Communicating includes intercepting a low level instruction and generating transmission control protocol socket connection. Communicating includes: generating a socket, identifying the socket, connecting to a client, sending and receiving messages to and from the client, translating the messages to transmission layer packets communicating with the driver and closing the socket. The software module comprises an application programming interface. The hardware module comprises an emulation of hardware. The hardware module comprises physical hardware components. The hardware module comprises a system-on-chip configuration. The Peripheral Component Interconnect express driver enables software defined network testing and hardware testing.

In another aspect, a device comprises a memory for storing information including a kernel, wherein the kernel includes a device driver configured for communicating with a system-on-chip configuration using one or more sockets and a processing component coupled to the memory, the processing component configured for processing the information. Communicating includes transmitting Peripheral Component Interconnect express transmission layer packets. The device driver is a Peripheral Component Interconnect express driver with Transmission Control Protocol sockets. The device driver is embedded in a kernel of the device. Communicating includes intercepting a low level instruction and generating transmission control protocol socket connection. Communicating includes: generating a socket, identifying the socket, connecting to a client, sending and receiving messages to and from the client, translating the messages to transmission layer packets communicating with the driver and closing the socket. The device driver enables software defined network testing and hardware testing.

In another aspect, a method programmed in a device comprises generating a socket, identifying the socket, connecting to a client, sending and receiving messages to and from the client, translating the messages to transmission layer packets communicating with a device driver and closing the socket. The transmission layer packets are Peripheral Component Interconnect express transmission layer packets. The device driver is a Peripheral Component Interconnect express driver with Transmission Control Protocol sockets. The device driver is embedded in a kernel of the device. The device driver enables software defined network testing and hardware testing.

In another aspect, a system comprises a software stack, a system-on-chip hardware module and a Peripheral Component Interconnect express driver configured for communicating between the software stack and the system-on-chip hardware module, wherein the Peripheral Component Interconnect express driver utilizes transmission control protocol packets for communicating and is embedded in a kernel of the system. Communicating includes intercepting a low level instruction and generating transmission control protocol socket connection. Communicating includes: generating a socket, identifying the socket, connecting to a client, sending and receiving messages to and from the client, translating the messages to transmission layer packets communicating with the driver and closing the socket. The software stack comprises an application programming interface. The Peripheral Component Interconnect express driver enables software defined network testing and hardware testing.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.

FIG. 1 illustrates a diagram of a software-defined profile loading to a system-on-chip according to some embodiments.

FIG. 2 illustrates a custom PCIe device driver according to some embodiments.

FIG. 3 illustrates a flowchart of a method of software and hardware co-validation for SDN SoC according to some embodiments.

FIG. 4 illustrates a block diagram of an exemplary computing device configured to implement the software and hardware co-validation for SDN SoC method according to some embodiments.

DETAILED DESCRIPTION

In traditional networking Application Specific Integrated Circuits (ASIC), many operations such as packet parsing, lookup, and others are hardened. With the evolution of a software defined network (SDN), recent ASIC technologies allow networking features to be defined in the software (as shown in FIG. 1). With a given collection of Application Programming Interfaces (APIs), a given individual/team is able to generate a fully customized profile to suit his/her/their needs. The collection of APIs through the TCP socket are able to be thought of along the same line as the OSI Layer. At the lower levels, the hardware APIs represent the actual configuration of the hardware which is able to be represented as hardware.write(address, data) or hardware.read(address,data). The Peripheral Component Interconnect express (PCIe) Device Manager takes these hardware transactions and configures the System-on-Chip (SoC) via TCP Socket. Furthermore, on the hardware side, the transaction from the TCP Socket feeds into a PCIe driver which actually does the signal-level pin toggling of System-on-Chip's PCIe core logic.

Multiple devices are able to be configured via the TCP socket, allowing for a single point of control when setting up a cloud of SDN devices/chips.

FIG. 1 illustrates a diagram of a software-defined profile loading to a system-on-chip according to some embodiments. A software stack 100 includes an API, a hardware manager, a PCIe Device manager, a TCP socket and/or any other drivers or interfaces. The software stack 100 is able to communicate with a SoC 102 through a custom PCIe device driver 104 with TCP sockets. The SoC 102 includes core logic and PCIe logic. By using the PCIe driver with TCP sockets (or another implementation), the software stack 100 and the SoC 102 are able to be tested. For example, test messages or communications are able to be sent, and the results or return values are able to be analyzed. The SoC 102 is able to be hardware or an emulation of hardware.

Software and SDN Application

Software used to program network ASICs has a very high level of abstraction, with several layers of APIs and feature specific code. Using these APIs, specific profiles are able to be developed and used by individuals/teams. A profile, in this case, refers to a particular device configuration enabling the device to carry out certain network functions.

For an SDN SoC, these profiles control the hardware device, hence they are important during deployment. Although the majority of software testing is done using the white model, this does not completely guarantee seemless integration with the post-silicon hardware. In the hardware section, a more robust approach to testing SDN software is discussed.

Furthermore, as SDN evolves, complicated hardware to support SDN-based configurations will be developed and will have a need to be verified end-to-end. One of the challenges in verification of an SDN SoC is that without some configuration from software, the ASIC will do very little. Software is what is used to define the feature set to overlay. Traditional hardware verification methods are able to be used to verify the hardware; however, whether or not this particular hardware is able to actually perform the features that the SDN defines are not able to be verified using a traditional simulation.

Software is important to ensure that an SDN SoC is able to function as a traditional packet processor. SDN provides a clear benefit to a user in that it provides flexibility to define features that their application utilizes.

Hardware

To verify a significant amount of the software stack, prior to post-silicon, a simulation-based or hardware-accelerated design (full-chip/device) is used. This allows verification and software engineers to quickly find bugs in both hardware and software within a reasonable amount of time. This approach also allows key features such as learning and table aging to be tested in real-time.

Although the device is able to be configured and initialized via many different interfaces, the primary and most common route is through PCI express (PCIe). Connected to the PCIe interface is a translator/driver, which converts messages to PCIe Transition Layer Packets (TLPs) and vice-versa. The driver is attached to the device, and it will also be simulated/emulated.

Communicating with Hardware

In an actual network environment, an application or software is running on a server communicating with the hardware device via direct connections. In the absence of the actual device, a key challenge is the communication mechanism used in the simulation/emulation environment. The communication mechanism should be light, fast, bi-directional, and transparent to the end user.

The method described herein allows communications between hardware and software via PCIe, using TCP sockets and messages as the communication medium.

PCIe root complex <----> TCP messages <----> host PCIe endpoint

The following is used to correctly set up and establish a connection and transfer messages.

1) create socket

2) identify socket

3) wait for incoming connection

4) client to connect

5) send and receive messages

6) translate messages to PCIe TLPs communicating with PCIe device Manager/Driver

7) close socket.

A key factor in maintaining a transparent layer is by embedding the code/logic in the lowest PCIe layer which resides in the software kernel space as shown in FIG. 2. On the hardware side, a similar approach is used but is separated into two parts—the TCP layer and the PCIe driver.

FIG. 2 illustrates a custom PCIe device driver according to some embodiments. The custom PCIe device driver 104 is used to correctly set up and establish a connection and transfer messages. The custom PCIe device driver 104 creates a socket, identifies the socket, waits for an incoming connection, client connection, sends and receives messages, translates messages to PCIe TLPs communicating with PCIe device Manager/Driver, and closes the socket. The custom PCIe device driver 104 is able to be used to verify the hardware (and hardware features) and the software stack in one step. Although PCIe is described herein, other interfaces are able to be utilized.

FIG. 3 illustrates a flowchart of a method of software and hardware co-validation for SDN SoC according to some embodiments. After APIs and an SDN SoC are developed, a PCIe driver is used to enable communication and thus testing between the APIs and the SDN SoC. The PCIe driver is utilized by generating a socket in the step 300. For example, after intercepting a low level instruction, a socket is generated. In the step 302, the socket is identified (e.g., given a socket identifier). In the step 304, the PCIe driver waits for an incoming connection. In the step 306, a client connects to the PCIe driver. In the step 308, messages are sent to and received from the client. In the step 310, the messages are translated to PCIE TLPs communicating with the PCIe device manager/driver. In the step 312, the socket is closed. Additional testing steps are able to be implemented after the socket is closed. For example, analysis of the results (e.g., return values) of the communications is able to be performed. Furthering the example, the PCIe driver is able to be used to perform signal-level pin toggling of the SoC's PCIe core logic. Multiple devices are able to be configured via TCP sockets. In some embodiments, fewer or additional steps are implemented. In some embodiments, the order of the steps is modified.

FIG. 4 illustrates a block diagram of an exemplary computing device configured to implement the software and hardware co-validation for SDN SoC method according to some embodiments. A computing device 400 is able to be used to acquire, store, compute, process, communicate, receive, send, and/or display information such as data packets. In general, a hardware structure suitable for implementing the computing device 400 includes a network interface 402, a memory 404, a processor 406, I/O device(s) 408, a bus 410 and a storage device 412. The choice of processor(s) is not critical as long as suitable processor(s) with sufficient speed are chosen. The memory 404 is able to be any conventional computer memory known in the art. The storage device 412 is able to include memory, a hard drive, CDROM, CDRW, DVD, DVDRW, High Definition disc/drive, ultra-HD drive, flash memory card or any other storage device. The computing device 400 is able to include one or more network interfaces 402. An example of a network interface includes a network interface controller or a network card connected to an Ethernet or other type of Local Area Network (LAN). The I/O device(s) 408 are able to include one or more of the following: keyboard, mouse, monitor, screen, printer, modem, touchscreen, button interface and other devices. Software and hardware co-validation for SDN SoC application(s) 430 used to perform the software and hardware co-validation for SDN SoC method may be stored in the storage device 412 and memory 404 and processed as applications are typically processed. More or fewer components shown in FIG. 4 are able to be included in the computing device 400. In some embodiments, software and hardware co-validation for SDN SoC hardware 420 is included. Although the computing device 400 in FIG. 4 includes applications 430 and hardware 420 for the software and hardware co-validation for SDN SoC method, the software and hardware co-validation for SDN SoC method is able to be implemented on a computing device in hardware, firmware, software or any combination thereof. For example, in some embodiments, the software and hardware co-validation for SDN SoC applications 430 are programmed in a memory and executed using a processor. In another example, in some embodiments, the software and hardware co-validation for SDN SoC hardware 420 is programmed hardware logic including gates specifically designed to implement the software and hardware co-validation for SDN SoC method.

In some embodiments, the software and hardware co-validation for SDN SoC application(s) 430 include several applications and/or modules. In some embodiments, modules include one or more sub-modules as well. In some embodiments, fewer or additional modules are able to be included.

Examples of suitable computing devices include a server, a personal computer, a laptop, a mobile device (e.g., smart phone), a network switch, a router, a hub, any other networking equipment and any other computing devices.

To utilize the software and hardware co-validation for SDN SoC method and system, software and hardware (or an emulation of hardware) are developed. Specifically, software and an emulation of hardware are developed for an SDN SoC. The software and hardware are then able to be tested using PCIe (or another implementation) utilizing sockets and messages as the communication medium. For example, after an individual/team generates one or more APIs and develops hardware or an emulation of the hardware, the individual/team or another entity is able to test the software and hardware using the software and hardware co-validation for SDN SoC method and system.

In operation, the software and hardware co-validation for SDN SoC method and system enable communication between hardware and software via PCIe using TCP sockets and messages which permits efficient testing and analysis of software and hardware aspects of an SoC. An entire software stack as well as hardware are able to be tested. Additionally, multiple chips (SoCs) are able to be programmed at the same time, not just one, as in previous implementations.

The present invention has been described in terms of specific embodiments incorporating details to facilitate the understanding of principles of construction and operation of the invention. Such reference herein to specific embodiments and details thereof is not intended to limit the scope of the claims appended hereto. It will be readily apparent to one skilled in the art that other various modifications may be made in the embodiment chosen for illustration without departing from the spirit and scope of the invention as defined by the claims.

Claims

We claim:

1. A software and hardware co-validation system comprising:

a hardware module for a programmable microchip including one of a group consisting of hardware and emulation software that emulates the hardware, the emulation software stored on a first non-transitory computer-readable medium;

a software module stored on a second non-transitory computer-readable medium and including a plurality of application programming interfaces (APIs) that together define a system profile including configuration data for a plurality of functions, wherein the APIs are not programmed into the hardware, but are designed to be programmed into the hardware, and when programmed into the hardware, the APIs enable the hardware to perform the functions of the system profile using the configuration data, and a first Peripheral Component Interconnect express (PCIe) driver configured for receiving and transmitting data between the APIs and the hardware module; and

a second Peripheral Component Interconnect express (PCIe) driver separate from the hardware module and configured for translating and communicating messages between the first PCIe driver of the software module and the hardware module.

2. The system of claim 1 wherein the translating and communicating messages includes intercepting a low level instruction and generating transmission control protocol socket connection.

3. The system of claim 1 wherein the translating and communicating messages includes:

generating a socket;

identifying the socket;

connecting to a client;

sending and receiving messages to and from the client;

translating the messages to transmission layer packets communicating with the driver; and

closing the socket.

4. The system of claim 1 wherein the hardware module comprises an emulation of hardware.

5. The system of claim 1 wherein the hardware module comprises physical hardware components.

6. The system of claim 1 wherein the hardware module comprises a system-on-chip configuration.

7. The system of claim 1 wherein the second PCIe driver enables software defined network testing and hardware testing.

8. The system of claim 1 wherein the second PCIe driver utilizes transmission control protocol packets for communicating and is embedded in a kernel of the system.

9. A software and hardware co-validation device comprising:

a memory for storing information including a device driver configured for communicating with a programmable system-on-chip configuration, wherein the device driver is communicatively coupled with a hardware module and a client having a stack, the hardware module including one of a group consisting of hardware and emulation software that emulates the hardware and the stack including a plurality of application programming interfaces (APIs) that together define a system profile including configuration data for a plurality of functions, wherein the APIs are not programmed into the hardware, but are designed to be programmed into the hardware, and when programmed into the hardware, the APIs enable the hardware to perform the functions of the system profile using the configuration data, and a first Peripheral Component Interconnect express (PCIe) driver configured for receiving and transmitting data between the APIs and the hardware module; and

a processing component coupled to the memory, the processing component configured for processing the information, wherein the device driver is separate from the hardware module and the communicating facilitated by the device driver is between the first PCIe driver of the client and the hardware module.

10. The device of claim 9 wherein the communicating includes transmitting PCIe transmission layer packets.

11. The device of claim 9 wherein the device driver is a second PCIe driver with Transmission Control Protocol sockets.

12. The device of claim 9 wherein the device driver is embedded in a kernel of the device.

13. The device of claim 9 wherein the communicating includes intercepting a low level instruction and generating transmission control protocol socket connection.

14. The device of claim 9 wherein the communicating includes:

generating a socket;

identifying the socket;

connecting to the client;

sending and receiving messages to and from the client;

closing the socket.

15. The device of claim 9 wherein the device driver enables software defined network testing and hardware testing.

16. A method programmed in a software and hardware co-validation device, the method comprising:

with the software and hardware co-validation device:

facilitating communication between a hardware module for a programmable microchip including one of a group consisting of hardware and emulation software that emulates the hardware and a first Peripheral Component Interconnect express (PCIe) driver of a client by:

generating a socket;

identifying the socket;

connecting to the client;

sending and receiving messages to and from the client;

translating the messages to transmission layer packets; and

closing the socket;

wherein the software and hardware co-validation device is separate from but communicatively coupled with:

the hardware module; and

the client, wherein the client has a stack including both a plurality of application programming interfaces (APIs) that together define a system profile including configuration data for a plurality of functions, wherein the APIs are not programmed into the hardware, but are designed to be programmed into the hardware, and when programmed into the hardware, the APIs enable the hardware to perform the functions of the system profile using the configuration data and a first Peripheral Component Interconnect express (PCIe) driver configured for receiving and transmitting data between the APIs and the hardware module, and further wherein the device is a second Peripheral Component Interconnect express (PCIe) driver.

17. The method of claim 16 wherein the transmission layer packets are PCIe transmission layer packets.

18. The method of claim 16 wherein the device is embedded in a kernel of the device.

19. The method of claim 16 wherein the device enables software defined network testing and hardware testing.

20. A software and hardware co-validation system comprising:

a programmable system-on-chip hardware module including one of a group consisting of hardware and emulation software stored on a first non-transitory computer-readable medium that emulates the hardware;

a software stack stored on a second non-transitory computer-readable medium and including a plurality of application programming interfaces (APIs) that together define a system profile including configuration data for a plurality of functions, wherein the APIs are not programmed into the hardware, but are designed to be programmed into the hardware, and when programmed into the hardware, the APIs enable the hardware to perform the functions of the system profile using the configuration data, and a stack Peripheral Component Interconnect express (PCIe) driver configured for receiving and transmitting data between the APIs and the system-on-chip hardware module; and

a validation Peripheral Component Interconnect express (PCIe) driver independent of the stack PCIe driver and the system-on-chip hardware module and configured for translating and communicating messages between the stack PCIe driver of the software stack and the system-on-chip hardware module.

21. The system of claim 20 wherein the translating and communicating messages includes intercepting a low level instruction and generating transmission control protocol socket connection.

22. The system of claim 20 wherein the translating and communicating messages includes:

generating a socket;

identifying the socket;

connecting to a client;

sending and receiving messages to and from the client;

closing the socket.

23. The system of claim 20 wherein the validation PCIe driver enables software defined network testing and hardware testing.

24. The system of claim 20 wherein the validation PCIe driver utilizes transmission control protocol packets for communicating and is embedded in a kernel of the system.