Programmability is a powerful concept. It allows us to build a physical machine and then modify, upgrade, repurpose, repair, and evolve it – without having to alter the original physical hardware. It allows us to design one device to serve multiple purposes, with variants, upgrades, and value-added features enabled with the flip of a few bits. Programmability extends the life of equipment in the field, reduces inventory requirements, simplifies maintenance and diagnostics, and often eliminates the need to roll a service truck altogether. 

In the world of networking, programmability promises these enormous benefits in the extreme. With the global bandwidth glut, network build-out has been a high-stakes, high-priority, big-revenue, full-throttle enterprise for the past three decades – and it shows no signs of letting up anytime soon. If you’re designing network hardware, you already know the drill. You design around the bleeding-edge of what’s possible with current hardware, often against standards that are still in flux, in a race against other companies’ engineering teams that are just as daring and terrified as you are. If you’re conservative in any aspect of your project, you might as well pack it in. If you take a risk and make a critical miscalculation, better spruce up your resume. Literally billions are at stake, and you won’t get a share of them if you can’t take the heat.

The concept of software-defined networking (SDN) has been around for the past five years or so. The idea is solid – abstract away as much of the capability as possible so that you can create the maximum flexibility using software. Typically, this means the control plane (the part of the network that decides where traffic should go) is abstracted from the data plane (the part of the network – usually hardware – that actually moves the data around). This approach obviously allows some flexibility in the definition and configuration of the network in software. But – what if the part you need to change is in the data plane? 

Historically, FPGAs have been the go-to devices for data plane network implementation. Using FPGAs allowed the design team to wait as late as possible in the design cycle to nail down details of the network protocol (as late as AFTER the design was complete, in many cases) and have the performance and programmability of the FPGA to handle the heavy lifting when the system went online. For this reason, communications and networking has been the largest segment of the FPGA market – since there has been an FPGA market.

But, what if you want to combine the power of software-defined networks with the programmability of FPGAs? What if you don’t want to have a huge part of your team dedicated to the vagaries of FPGA implementation? What if you’d like to build a single line card that could generically solve a wide range of problems by taking advantage of both software and hardware programmability in both the control and data planes?

Xilinx wondered exactly the same thing, and thus we now have what the company calls “softly-defined” networks. Softly-defined networks pick up where SDN leaves off – making both the hardware AND the software programmable. Xilinx calls their initiative the “Software Defined Specification Environment for Networking (SDNet).” SDNet is the closest thing we’ve ever had to a turnkey platform for the design of high-performance packet processing systems. What do we mean by “turnkey”? We mean that you can compile a high-level specification into a hardware/software implementation on a Xilinx device – without having to be an expert in VHDL or Verilog.

One of the not-so-big secrets of the networking world is that one of the critical cost-reduction phases just doesn’t seem to happen anymore. In the old days, the FPGA version of a network platform was released first, and it went to market to fill the needs until a cost-reduced version could be built using ASICs. For the past couple of generations, however, that ASIC step has gotten too expensive, too time consuming, and too high-risk. Before we had time to make the ASIC version, it was time to move on to new things – and those things included FPGAs.

In Xilinx’s SDNet world, your system architect defines the specifications for the network in an “intuitive” high-level environment. The company claims that these specifications allow the packet processing functions to be described in a natural way, without any implementation detail. These specifications are then processed by an integrated set of development tools into an “optimized hardware implementation” on Xilinx devices – including the hardware blocks for specific functions such as parsing and editing, packet data plane subsystems, custom firmware to support the generated architecture, and test benches for design validation.

As a bonus, Xilinx says the architectures generated support “hitless updates,” meaning that the data plane can be altered between packets with no disruption to line-rate service. The hardware configurations generated by the system take advantage of Xilinx’s SmartCORE networking IP, and LogiCORE IP for connectivity, external memory control, and embedded processors. If you’ve got your own IP already designed, you can easily include that as well.

Xilinx says that SDNet offers scalable line rates from 1G through 400G with the same source code – compiled into various hardware configurations to support the desired line rate. The system will automatically optimize the implementation for the best performance and power consumption – targeting the lowest-cost Xilinx device that will handle the application. SDNet works across the whole spectrum of Xilinx devices – including the Zynq family (with on-chip multi-core ARM processing subsystems). 

Xilinx happily points out that the entire line card (with the exception of optics and external memories) can be implemented in their “All Programmable” devices. Of course, that’s a win for Xilinx business-wise, but it also is a critical component in the realization of a truly hardware- and software-programmable networking solution.

As the FPGA market has matured, one of the biggest obstacles to increased adoption has been the learning curve required for FPGA design. As FPGAs expand into new markets and new applications, it becomes clear that there is no magic, unified language or environment that will facilitate the use of programmable logic in all application domains. Therefore, it is incumbent on the companies who want to sell FPGAs to create smooth design flows tailored specifically to the needs of their most important problem domains. There is no better place to start than with the biggest FPGA market of them all – and that is exactly what Xilinx has done here – following the timeless rule: “Dance with the one that brung ya.”