Software Defined Specification Environment for …...Xilinx dubs the next-generation programmable networking platform as the “Softly Defined Networking” devi ce, highlighting the

©Copyright 2014 Xilinx

Software Defined Specification Environment for Networking (SDNet)

March 2014 www.xilinx.com/sdnet 2©Copyright 2014 Xilinx

Enabling the Industry’s First “Softly” Defined Networks

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The need for Softly Defined Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

SDNet Specification Environment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Next generation line cards and Softly Defined Networks via SDNet . . . . . . . . . . . . . . . . . . . . . . . . . 7

SDNet descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

SDNet methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

SDNet flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Xilinx underpinning technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Comparison with alternative approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

http://www.xilinx.com

Enabling the Industry’s First “Softly” Defined Networks

IntroductionAs the culmination of many years of research and extensive investment, Xilinx is introducing its new Software Defined Specif ication Environment for Networking (SDNet). SDNet enables the easy creation of high performance packet processing systems, based on compiling high-level user defined specif ications to highly optimized All Programmable FPGAs and SoCs. More specif ically, SDNet in conjunction with Xilinx All Programmable devices enables the creation of “Softly” Defined Networks, a technology dislocation. Softly Defined Networks not only support the objectives of SDN but also allows for game changing capabilities through support of software defined data plane hardware with content intelligence.

The target audience for this document includes networking system architects and engineering managers who wish to understand the broad capabilities of SDNet, in order to determine how SDNet can be applied to solve their challenging technical problems and ultimately to construct Softly Defined Networks that are both All Programmable and Smarter. While reading this document, the reader will be able to do deeper dives into particular aspects of interest by consulting companion documents covering specific features of SDNet.

The need for Softly Defined NetworksTo address ever-evolving end-user demands, networking system vendors realize that their development cycles must shrink from years to months and must also support new networking topologies which include SDN. This is driven by the rapid evolution of standards, new connectivity options, and the emergence of over-the-top services that must be deployed dynamically and in a uniform fashion, scaling across multiple line cards that vary in throughput, interface options and sizes. At the same time carriers are looking at new network architectures such as SDN and NFV to realize simplicity in provisioning, management and capital expenditure. The ideal solution is a truly programmable and scalable line card, from ingress to egress, that accommodates new functions to be deployed, under software control, with customized hardware implementations.



The need for Softly Defined Networks

The extreme rising development costs, extended development cycles and inherent lack of flexibility inhibit equipment providers from their traditional migration to next generation ASICs. Even successful ASIC projects have amassed additional “future-proofing” resources, thereby adding noticeable cost, size, and power, overheads. Overall, very few system vendors have attempted to scale their internal data plane ASICs beyond 50-100 Gbit/sec data rates. Meanwhile, the disparate requirements of new applications and data rates affect ASSP vendors in a similar fashion, thereby creating merchant silicon delivery gaps. Simply stated, the business case for f ixed silicon solutions is rapidly evaporating.

While ASIC and ASSP vendors grapple with the challenges of the networking realm, the IT industry is pushing through new boundaries. One emergent trend is for IT architects to see hardware evolving towards a set of dynamic virtual services under software control, and as such brings to question the value of the line cards populated with fixed-function ASICs and more flexible merchant NPUs. However, solutions based upon simple switching hardware only, with higher functions left to software, are not able to deliver performance requirements, except in very limited contexts.

The potential that All Programmable FPGAs and SoCs hold in addressing the need for highly flexible hardware that can be programmed via software cannot be overstated. Virtually every function of the line card – from ingress through egress – can be implemented via programmable technologies using today’s All Programmable devices while supporting the requisite line rates and packet processing rates associated with next generation network platforms.

Xilinx dubs the next-generation programmable networking platform as the “Softly Defined Networking” device, highlighting the All Programmable nature of both software and hardware and the capability to address functionality that includes and goes beyond SDN.

Software Defined Networks

Software DefinedControl Plane with

Network Intelligence

Fixed Data Plane Hardware

OpenX…Southbound API

“Softly” Defined Networks

Software DefinedControl Plane with

Network Intelligence

Software Defined Data Plane Hardware with Content Intelligence

OpenX…Southbound API

• Virtual Network Services

• Network Flexibility

• Holistic Management

Benefits & Capabilities

SDNet Software Defined Specification Environment

All Programmable FPGAs and SoCs

• Wire Speed, Protocol Complexity Agnostic

• Per-flow, Flexible Services Provisioning

• In-service ‘Hitless’ Updates

Figure 1: The evolution to Softly Defined Networking



SDNet Specification Environment overview

Figure 1 illustrates the evolution of the network device (switch, router, or appliance). The first step shows the widespread trend towards Software Defined Networking, with open and flexible software control, but closed, f ixed and simple hardware. The second step shows the further Xilinx step to Softly Defined Networking, with open, flexible and complex hardware data planes to address the performance and security challenges of modern differentiated content-oriented networking. The limited Southbound API of Software Defined Networking becomes much richer: supporting substantial reprogramming of the high speed data plane, and retrieving programmed traff ic analyses from the data plane. The additional benefits derived from the software defined data plane hardware are quite profound and include: wire-speed protocol-agnostic support; improved, highly flexible Quality of Service (QoS); flow and session aware capabilities, in addition to enabling network virtualization, Network Functions Virtualization (NFV), and user defined, custom capabilities.

The revolutionary Xilinx SDnet Specification Environment addresses the transition to Softly Defined Networking, enabling rapid prototyping, development and deployment of packet processing functions on Xilinx All Programmable devices. The introduction of a high-level functional specif ication approach that enables automatic mapping of packet processing requirements to an optimal programmable hardware implementation is truly an industry changing and disruptive technology.

SDNet Specification Environment overviewThe cornerstone of the SDNet environment is the use of high-level networking specifications, which are processed by a set of integrated development tools. This allows a user to describe required packet processing functions in a natural way, without including any implementation detail. The specif ication is then automatically transformed into an optimized hardware implementation on Xilinx All Programmable devices that delivers line rate performance at optimal cost, power and performance. This realizes the nirvana of softly defined networking.

The main components of the SDNet integrated development environment are:

° Generation of custom hardware components for specif ic functions (e.g., parsing, editing)

° Generation of custom packet data plane hardware subsystems to meet user requirements

° Generation of custom firmware for generated SDNet hardware architectures

° Generation of test benches for debugging and validation

The packet processing architectures generated by the SDNet environment support hitless updates: where changes to the data plane processing functionality can be made between packets with no disruption to line-rate service whatsoever. These in-flight changes are enabled via custom firmware updates that are also generated via SDNet specification changes made by the user.



SDNet Specification Environment overview

SDNet also includes integration of other Xilinx optimized SmartCOREs™ for networking, and LogiCOREs™ for connectivity, external memory control, and embedded processors. This is achieved by coupling SDNet with the industry-leading Xilinx Vivado® design environment.

The SDNet environment is open-ended, to allow integration of user-provided components:

° Tight hardware integration: user engines imported into SDNet

° External hardware integration: user IP blocks linked to a complete SDNet hardware block

° Software integration: user software linked with SDNet management APIs

The key capabilities and benefits of the revolutionary SDNet are as follows:

Table 1: Key SDNet Capabilities

Capability Benefit

High-level specifications Empowers system architects to specify exact services to be implemented without needing FPGA design expertise

Wire speed processing Delivers the bit and packet rates required for next gen data center, edge, metro, and core, networks

Scalable line rates from 1G to 400G Same code used, with automatic compilation to hardware architecture supporting required rate

Customized hardware architecture Optimal resource used with no waste: can be targeted to the lowest cost and power All Programmable Device

Based on All Programmable Devices Implemented in industry-leading silicon technology, providing optimal programmable performance per Watt

Hitless service provisioning In-service upgrades possible with quick compilation times and no disruption to service for installation

Open-ended framework Ensures that “secret sauce” components and non-networking components can be seamlessly integrated



Next generation line cards and Softly Defined Networks via SDNet

Next generation line cards and Softly Defined Networks via SDNetFigure 2 shows an example of the functions that SDNet can realize on a typical line card.

Optics

MACPCS

/FEC

ProgrammablePacket Processor

External Memory

Backplane

ProgrammableTraffic Manager

Hierarchical QoS

Per-flow GranularityFabric

I/F

Softly Defined Line Card

Parsing Embed. Search

Editing

External Memory Interfaces:DDR4, RLDRAM, QDR, SERIAL

LogiCOREsSmartCOREs

SmartCOREs

External TCAM

External TCAM InterfaceFPGA/SoC

SmartCORE

Figure 2: Example SDNet Softly Defined line card

As shown in Figure 2, with the exception of the optics and external memories, it is possible to realize a line card supporting next generation services entirely out of All Programmable devices. The SDNet specification environment does indeed make the All Programmable line card both possible and practical. In the block diagram above, a custom data plane comprised of both a packet processing and programmable traffic manager can be specified via the SDNet environment. Also, as shown above, the MAC, PCS, FEC and fabric interface cores can also be sourced from Xilinx’ extensive SmartCORE networking library; other basic interface cores, including external memory interfaces, are also available from Xilinx’ LogiCORE IP library.

A very unique capability of the SDNet specif ication environment is the ability to generate datapath processing functions that support hitless, in-service updates. As such, the different line card components can be updated with new features or capabilities using a software controller via standard SDNet APIs. The updating software can run on an embedded soft processor or on an external processor. When the target is a Xilinx Zynq® All Programmable SoC, the software can run



Next generation line cards and Softly Defined Networks via SDNet

on the device’s embedded ARM® processor. So SDNet offers an extra dimension to Softly Defined Networking: full hardware programmability under software control.

Figure 3 shows different possible deployments of SDNet-based solutions within the network.

Figure 3: Example SDNet‐based network deployments



SDNet descriptions

SDNet descriptionsThe evolution of computer science has involved increasing abstraction towards describing what has to be done in human terms, rather than how it should be done by machinery. Two well-known examples are SQL descriptions, where database queries are expressed in a natural form, without any details of how the underlying database is implemented, and HTML descriptions, where the appearance of a web page is expressed as a text mark-up, without any details of how the page is displayed on a particular device. Such descriptions are written in domain-specif ic languages that are customized for specific application areas. This makes them a practical compromise between an unrestricted natural language and standard computer programming languages.

In packet processing, the requirements of particular protocols are typically expressed in English language descriptions, such as Internet Requests for Comment (RFC) or ISO standards documents. However, these then have to be manually turned into low-level, implementation-specif ic, descriptions of how the packet processing should performed by general-purpose processors or specialized network processors, or by hardware designed into custom ASICs.

Because packet processing encompasses a relatively small number of characteristic functions, it is a good candidate for a customized approach that allows networking experts to describe required packet processing in a natural way; SDNet provides this capability. Moreover, SDNet provides an optimized compiler that translates and maps such specifications to efficient implementations, giving a high-level productivity benefit to users, who can target the appropriate underlying FPGA technology to realize a flexible and optimized hardware implementation.

SDNet allows users to describe the required behavior of various types of packet processing engines, including parsing, editing, search, and QoS policy, engines. It also allows users to describe engines hierarchically in terms of simpler sub-engines that are inter-connected with packet data flows. These sub-engines can include user-provided engines. The SDNet description contains no implementation details, which enables users to scale the performance, power, and resources of their design without any re-programming. SDNet is also not limited to any specif ic network protocols.



SDNet descriptions

An example of part of a packet parsing function, for traversing Ethernet packet headers, is shown in Figure 4, with the corresponding SDNet description shown in Figure 5. The general traversal process involves being at a certain bit offset within a packet, which is expected to be a certain type of section (which could be a header, trailer, or other packet part of interest), doing operations, and then moving to a next section or terminating if complete. This example shows how certain Ethernet header fields of interest are extracted and placed into a 12-tuple, which can then be used later for classif ication using a connected search engine.

A complete packet parser contains a collection of similar classes, one for each protocol header type. Each class contains a declaration of the header format, together with methods that define rules for traversal to the next header of interest: its type and offset within the packet. Packet editing involves a similar traversal of headers or trailers of a packet, and may also include the insertion or removal of headers or trailers.

Inputs

Packet

Section type: ETH (= Ethernet)

Bit offset in packet

12-tuple: fields

Outputs

Packet (unchanged)

Next section type: VLAN or IP, or done with error code 1

Next bit offset in packet: 112 (= 48+48+16) bits later

12-tuple: fields with dmac, smac and type set

Figure 4: Example of parsing the ETH step



SDNet descriptions

class OF_parser::ParsingEngine (9000,4) {

// Tuple class for extracted data class Flow :: Tuple(inout) { struct flow_s { // OpenFlow 12-tuple port:3, dmac:48,smac:48,type:16, // Eth vid:12,pcp:3, // VLAN sa:32,da:32,proto:8,tos:6, // IP sp:16,dp:16 // TCP } } Flow fields;

// Section class for Ethernet header class ETH :: Section { struct {dmac:48, smac:48, type:16} method update = { fields.dmac = dmac, fields.smac = smac, fields.type = type } method move_to_section = if (type == 0x8100) VLAN else if (type == 0x0800) IP else done(1); method increment_offset = size(); }

// VLAN, IP, TCP classes follow ... // Similar style to ETH class

}

Figure 5: SDNet description of ETH parsing

March 2014 www.xilinx.©Copyright 2014 Xilinx

class MPLS_LSR::System { // Input and output interfaces Packet_input instream; Packet_output outstream;

// Sub-engines MPLS_Classifier classifier; Secret_Sauce relay; MPLS_Editor editor;

// Interconnections method connect = { classifier.packetin = instream, relay.in = classifier.packetout, editor.packetin = relay.out, editor.fields = classifier.fields, editor.op = classifier.op, outstream = editor.packetout }}

// ...

class Secret_Sauce :: UserEngine { Packet_input in; Packet_output out;}

Figure 6: SDNet description of MPLS_LSR system

com/sdnet 11


SDNet descriptions

Figure 7: Example of engine composition: the MPLS_LSR system

Users can compose engines by interconnecting various component sub-engines into a packet data flow macro-architecture. The described interconnection pattern can follow any directed acyclic graph. A simple example, illustrating the composition of an engine from three component sub-engines is shown in Figure 7, with the corresponding SDNet description shown in Figure 6 . The SDNet description shows just the data flows between engines, without any implementation detail being given. This SDNet description fragment also includes the description of a user-provided engine, which is characterized only by its input and output interfaces. Here, the user engine is present to perform some custom transformation on the main packet stream, prior to packet editing that is driven by a packet classif ication result. In this example, the editor has one packet stream input, and two additional data tuple stream inputs.

The compositional methodology is central to the SDNet approach to distributed search engines. There are three classes of search engine included in SDNet:

° Content addressable memory (exact match)

° Longest-prefix match engine

° Ternary content addressable memory (wildcard match)

In an SDNet description, the user can specify the sizing – key and result width, and lookup table depth – of search engines, and then these engines are integrated within an overall system data flow architecture as required by the application. Thus, the overall search capabilities are optimized for the particular application.

An example of using a representative collection of application-customized search engines together is:

° Exact match CAM for Ethernet destination address lookup: 64K entries, 48 bits wide

° Exact match CAM for Ethernet source address learning: 4K entries, 48 bits wide

° Longest-prefix match for IPv4 destination address lookup: 64K entries, 32 bits wide



SDNet descriptions

° Longest-prefix match for IPv6 destination address lookup: 8K entries, 128 bits wide

° Ternary CAM for ACL lookup: 4K entries, 112 bits wide

This would feature in comprehensive handling of Ethernet/IP/TCP/UDP packets. Each search engine is individually sized and optimized for the precise application requirement, and is directly coupled to the relevant packet processing engines, avoiding bottlenecks.

srTCM

trTCM

mefTCM

Precision

Red

WRED

Tail Drop

FC

Precision

Token Bucket

Leaky Bucket

Single: CIR

Dual: CIR-PIR

SP

RR

WRR

DWRR

SP + [any]

QoS: Deterministic and Precise, Dynamically Controlled

Congestion Avoidance Shaping SchedulingMetering/

Policing

Figure 8: Example of policy engine composition

A similar compositional approach is taken for Quality of Service (QoS) by composing interconnected policy engines. The required services provisioning – number of flows and number of levels of hierarchy – can be specif ied by the designer, together with the selection of granular policing, shaping, scheduling, accounting, or congestion management, algorithms for each flow. The overall QoS policy capability is optimized for the particular application and is encapsulated, together with the related packet processing for flow classif ication and packet marking, within automatically generated components.

Figure 8 shows an example of a combination of policies that could be maintained per flow as a packet is traversing multiple levels of QoS hierarchy. A policing profile is chosen (here, Two-Rate Three-Color Marking), and then an appropriate congestion avoidance measure is assigned (here, Weighted Random Early Detection with Flow Control between hierarchy levels). A shaping profile for outgoing packets is chosen (here, Dual Leaky Bucket) and then a scheduling discipline is applied (here, Strict Priority Plus).

In short, SDNet specif ications involve descriptions that are natural, short and easy for the user, while the customized FPGA implementation makes the packet processing eff icient and fast, with very low power consumption.

The SDNet packet processing data plane hardware generated from the user specification is complemented by the generation of stubs for wide-ranging management functions accessible by control plane software, including hitless updates to all packet processing functions, and the collection of traffic



SDNet methodology

statistics and custom sketches. In this way, SDNet provides genuine softly defined networking: optimized and programmable hardware, in addition to accompanying control software, all driven from a high-level, implementation-independent, specification.

SDNet methodologyFigure 9 shows the overall design flow when using SDNet. Beginning with an SDNet description, the result is a bitstream for configuring a Xilinx All Programmable Device.

Figure 9: SDNet design flow

The f irst step involves using the SDNet compiler to generate an RTL-level description of the required hardware functionality. The user provides the compiler with additional information regarding performance (throughput and latency) requirements and run-time programmability requirements that influence the optimized hardware architecture generated by the compiler. In addition to the register-transfer level (RTL) hardware description, the compiler also generates stubs for software control functions, and debugging and validation infrastructure.

The second step involves using the foundation Xilinx Vivado design tools. This has two main functions. The f irst is to transform the RTL-level architecture description generated by the SDNet compiler into an optimized Xilinx FPGA implementation. The second is to enable the integration of this subsystem with other SmartCOREs and LogiCOREs to build a complete system, and generate the f inal optimized bitstream for the chosen Xilinx All Programmable Device family member.

The system integration function allows the SDNet data plane processing functionality to be included as a part of a larger system, which includes other user-supplied components and, in particular, interfacing SmartCOREs and LogiCORES to access, for example, Ethernet or Interlaken connectivity, or external DRAM or TCAM memories.



SDNet flexibility

SDNet also supplies infrastructure for debugging and validation at a number of levels. A test packet collection for input to the SDNet data plane (or optionally, as expected at the output of the SDNet data plane) can either be generated by the compiler or supplied by the user. The test packets can then be applied at three different levels:

° Interpretation of the SDNet specif ication

° Simulation of the RTL-level description generated by the SDNet compiler

° Hardware validation of the final implementation using network test equipment

In addition to the test packets, corresponding contents for search engine lookup tables can also either be generated by the compiler or supplied by the user.

The overall effect of the SDNet design flow is to seamlessly take the user’s high-level specification of packet processing requirements and automatically map this to a custom optimized SmartCORE.

SDNet flexibilityThe central value proposition of SDNet is the provision of optimized hardware for the exact line card data plane processing requirements, achieved through the use of Xilinx All Programmable device technology. The basic design flow means that design upgrades can be carried out in the field without physical hardware changes; a new bitstream can be generated, and the All Programmable Device can be reconfigured.

Not only can the All Programmable device be reconfigured but SDNet also supports hitless upgrades performed under software control, between packets being processed at line rate. In other words, users can quickly create and upgrade so that one packet is processed using the earlier version of the design, and the next packet is processed using the new version of the design. Figure 10 shows the extended version of the design flow that accommodates this feature.

The main addition is that the SDNet compiler also generates f irmware that configures many of the fine-grain functions of the packet processing data plane. The f irmware operations, and their binary encodings, are completely customized by the compiler for each individual component of the generated architecture. This gives an intimate level of control over the processing. Although very low-level f irmware, it is automatically generated from the SDNet description and is invisible to the user.

As shown in figure 10, the compiler maintains an SDNet architecture record between runs: this stores details of the generated architecture and its firmware. When users re-run the compiler with an updated SDNet description as input, it determines whether the update can be accommodated with a firmware update only without generation of new hardware, or whether a re-generation of the hardware (and firmware) is needed. In most cases, medium-scale updates, such as adding or subtracting a protocol handled by the line card, can be done through firmware updates only.



Xilinx underpinning technologies

Figure 10: SDNet design and update flow

The intimate connection between the firmware and the architecture, which are both generated by SDNet’s compiler, means that users can perform hitless upgrades, whereby the firmware is changed and placed into service without disrupting the flow of packets. In this way, companies can perform significant service upgrades without any interruption to the service. This revolutionary development is achieved through the unique nature of the SDNet technology and its coupling of high-level specifications with Xilinx All Programmable devices.

Xilinx underpinning technologiesXilinx All Programmable devices are able to implement complete line card data plane processors, allowing differentiated network protocol handling at full line rates scaling from 1 Gbit/sec to several 100 Gbit/sec. FPGAs that provide this level of capability represent the culmination of hundreds of person-years of design, involving expertise across a wide range of disciplines, focused on solving a wide range of challenges in a holistic manner.

The system-level problems that arise in designing a programmable device that can service the extreme requirements associated with next-generation packet processing are staggering. Terabits of data must flow in and out of an FPGA via state-of-the-art SerDes connectivity at multi-gigabit rates with the lowest latency, fanning out to internal busses that can reach in excess of 2048 bits in width through packet processing components operating at wire speed, with chip-wide clock skew and jitter budgets that are in the sub nanosecond realm, and all within miserly power budgets.

With the 7 series of All Programmable logic devices, and the more recently introduced UltraScale™ families, Xilinx has brought to bear a wide range of the industry’s leading edge technologies to address the demanding challenges of wire speed datapath processing. The 28nm Virtex®, Kintex®, and Artix® families have a wide range of networking-essential features, including transceivers that support 28 Gbit/sec, integrated PCIe 3.0 controllers, fully commercial 3D IC based products, and




the Zynq All Programmable SoC with integrated ARM Cortex A9 processing sub-system. This broad portfolio provides the requisite silicon platform that enables optimal f it, performance, and integration for networking equipment from the core to the edge of the network.

Building upon the success of the 7 series families, Xilinx introduced the UltraScale family, with an even greater focus on addressing the challenges of next-generation networking applications. UltraScale is the industry’s f irst, and only, architecture that delivers unprecedented levels of integration and capability with ASIC-class system-level performance. The UltraScale architecture scales from 20 nm planar through 16 nm FinFET technologies and beyond, in addition to scaling from monolithic through 3D ICs.

Through analytical co-optimization with the Xilinx Vivado Design Suite, the UltraScale architecture provides massive routing capacity while intelligently resolving typical bottlenecks in ways never before possible. This design synergy achieves greater than 90% utilization with no performance degradation.

To address the demands of differentiated next-generation networking applications, a wide range of features and capabilities have been included in the UltraScale family. These include:

° Massive data flow optimized for wide buses with multi-terabit throughput and low latency.

° Step function in inter-die bandwidth for 2nd-generation 3D IC systems integration and new 3D IC wide-memory optimized interface.

° Massive I/O and memory bandwidth, including support for next-generation DDR4 memories and Hybrid Memory Cube technologies.

° Multi-region ASIC-like clocking, delivering low-power clock networks with extremely low clock skew and high-performance scalability.

° Multiple hardened ASIC-class 100G Ethernet, 150G Interlaken, and PCIe, cores.

An overview of the 7 series and Ultrascale families is given in Table 2.

Table 2: Summary data for 7 Series and UltraScale families

Zynq‐7000 Artix‐7 Kintex‐7 Virtex‐7Kintex

UltrascaleVirtex

UltraScale

Logic Cells 277,400 215,360 477,760 1,954,560 1,160,880 4,407,480

Block RAM 3Mb 13Mb 34Mb 68Mb 76Mb 115Mb

DSP Slices 2020 740 1,920 3,600 5,520 2,880

DSP Performance(symmetric FIR) 2622 GMACs 930 GMACs 2,845 GMACs 5,335 GMACs 8,180 GMACs 4,268 GMACs

Transceiver Count 16 16 32 96 64 104

Transceiver speed 12.5 Gb/s 6.6 Gb/s 12.5 Gb/s 28.05 Gb/s 16.3 Gb/s 32.75 Gb/s




The Xilinx SDNet software environment is built upon the foundational Vivado design suite, which unleashes the full potential of the underlying All Programmable architecture family through analytical co-optimization between the design suite and the targeted device. As such, truly optimized solutions for cost, performance, and power, can be realized for a given data plane processing feature set. Because an SDNet specif ication is high level and independent of implementation, the user can automatically target the right functionality for the right device.

SDNet also benefits from inter-working with Vivado IP Integrator (IPI), which provides accelerated time for IP core integration to build larger systems. Built on the foundation of the Vivado integrated design environment, IPI is a device- and platform-aware interactive environment that supports intelligent auto-connection of key IP interfaces, one-click IP subsystem generation, real-time design rule checks, and interface change propagation, combined with a powerful debug capability. IPI employs Vivado design tools to ensure that designs and IP are configured correctly.With IPI, design is correct-by-construction. Working at the interface level, design teams can rapidly assemble complex systems. IPI’s built-in automated interface, device driver, and address map generation further accelerates design assembly.

Subsystems built using SDNet can be packaged as SmartCORE IP cores, and then larger systems can be built using IP Integrator to combine these generated SmartCOREs with other Xilinx SmartCOREs and LogiCOREs, 3rd Party Alliance Cores, and a user’s own IP cores. This can include software components running on embedded processor cores. Thus use of SDNet’s specialized capabilities can be combined with use of power tools specialized for other processing domains.

Total Transceiver Bandwidth(full duplex)

400 Gb/s 211 Gb/s 800 Gb/s 2,784 Gb/s 2,086 Gb/s 5,101 Gb/s

Memory Interface(DDR3) 2,400 Mb/s 1,066 Mb/s 1,866 Mb/s 1,866 Mb/s 2,133 Mb/s 2,133 Mb/s

Memory Interface (DDR4) 2,400 Mb/s 2,400 Mb/s

PCI Express® Interface x8 Gen2 x4 Gen2 x8 Gen2 x8 Gen3 x8 Gen3 x8 Gen3

Analog Mixed Signal XADC XADC XADC XADC SystemMonitor

SystemMonitor

Configuration AES Yes yes Yes Yes Yes Yes

I/O Pins 470 500 500 1,200 832 1,456

I/O Voltage 1.2V - 3.3V 1.2V - 3.3V 1.2V - 3.3V 1.2V - 3.3V 1.0 - 3.3V 1.0 - 3.3V

For additional details on the 7 Series and UltraScale families, please visit www.Xilinx.com

Table 2: Summary data for 7 Series and UltraScale families (Cont’d)

Zynq‐7000 Artix‐7 Kintex‐7 Virtex‐7 Kintex Ultrascale

Virtex UltraScale



Comparison with alternative approaches

Comparison with alternative approachesFigure 11 shows some of the main features of SDNet, compared with properties of alternative approaches to providing the required line-rate data path processing.

SDNet Alternative 1 Alternative 2

Description Portability

Packet Processing Flow

Lookup Tables

QoS Policies

Proprietary IP

No ChangeTo Scale Performance

Define OptimalPacket Flows

ConfigureAs Required

Feature RichGranular QoS

Integrated Hardware - 1ICBest Fit

HardwareRe-Design

Fixed Pipeline:Hard to Map

Same Size Tables:Waste Resources

Not Optimal;Scaling Challenges

Hardware: Two-ICsOverhead

Low-LevelRewrite

Multi-thread:Resource Conflicts

Shared Table:Access Conflicts

Fixed QoS:Inflexible

Software on Chip:Low Performance

X

Y X z

?

Flow bundles

END

END

END

Z

Figure 11: SDNet features compared with alternative approaches

The bottom line is that SDNet provides an optimally-resourced implementation: avoiding wasted unused resources present in a f ixed-provision technology. It also allows an optimally-architected implementation: a packet flow architecture matching the problem rather than that of a f ixed-architecture technology. Furthermore, the same SDNet packet processing specif ication can be used when either scaling up or scaling down performance requirements.

This characteristic – which has been built into SDNet from the ground up – is essential in an age with more and more emphasis on the virtualization of networks and network functions, and the software definition of such networks. It allows for hardware that provides the required performance, but also has the flexibility that is required to deal with rapid changes in functions, provisioning, protocols, and standards. This makes SDNet stand alone as the technology for the next generation.



Summary

SummaryThe Xilinx SDNet Specification Environment is a disruptive technology that empowers the networking system architect to readily realize new and innovative products, including those based upon both SDN and softly defined networks. SDNet greatly benefits from the extensive capabilities of Xilinx All Programmable devices, which have the capacity both to receive and transmit data at very high line rates, and also to perform the necessary line card data plane processing functions needed at all levels of the network. The SDNet breakthrough is in making this raw silicon capability readily available to a broader number of users through a very high-level design methodology that allows specif ication of what is required, rather than of how it should be implemented. This methodology combines both smart compilation for generating new system components and libraries of optimized SmartCOREs for standard networking functions. Combined with the ability to perform hitless in-field upgrades, and to provide for a software defined control plane with network intelligence and a software defined data plane with content intelligence, SDNet both reduces risk and time to market and enhances maintainability and extensibility. In short, SDNet is a key enabler in addressing the industry trend towards SDN while accelerating productivity for networking system designers and architects.

For additional details regarding SDNet, please contact your local sales off ice or Xilinx.com.



Documents

Software Defined Specification Environment for …...Xilinx dubs the next-generation programmable networking platform as the “Softly Defined Networking” devi ce, highlighting the