WP_Term Object
    [term_id] => 159
    [name] => Mentor, a Siemens Business
    [slug] => mentor-graphics
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 512
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 512
    [category_description] => 
    [cat_name] => Mentor, a Siemens Business
    [category_nicename] => mentor-graphics
    [category_parent] => 157
    [is_post] => 1

Verifying Software Defined Networking

Verifying Software Defined Networking
by Daniel Payne on 02-22-2019 at 12:00 pm

I’ve designed hardware and written software for decades now, so it comes as no surprise to see industry trends like Software Defined Radio (SDR) and Software Defined Networking (SDN) growing in importance. Instead of designing a switch with fixed logic you can use an SDN approach to allow for greatest flexibility, even after shipping product. For SDN the key feature is the configurable match action devices as shown below in the plum color:

SDN abstract forwarding model

Downloading a new configuration into a SDN device is typically through a Peripheral Component Interconnect Express (PCIe) interface, and can involve using a Virtual Machine (VM) over PCIe. There are many unique challenges in verifying the HW and SW for a SDN system:

  • Forwarding elements changing based on traffic type and service class
  • Load balancing
  • Performance monitoring
  • Operator control
  • Validating drivers and applications
  • Compliance of SW drivers with orchestrators
  • Handling data plane exceptions

Let’s look at some different approaches of using PCIe as the management port for verifying a modern SoC device like an SDN. The control and forwarding tasks are separated in SDN devices as shown below:

Example SDN HW Block Diagram

Everything shown above in blue can be configured, even on the fly. The Orchestrator configures the networking data plane and manages a single chip or multiple chips using a processor. SDN devices have a wide range of tasks:

  • Service routing
  • Bridging
  • Forwarding
  • Replication
  • Network Address Translation (NAT)
  • Multi-protocol Label Switching (MPLS)
  • Data Center Bridging (DCB)
  • Virtual extensible Local Area Networks (VXLAN)
  • Network Virtual General Record Encapsulation (NVGRE)
  • Generic Network Virtualization Encapsulation (GENEVE)
  • Spanning tree protocols

A vector-based verification (VBV) methodology could be used in different ways:


  • Software VBV
  • UVM
  • Advanced VBV

    With Software VBV the SDN SW creates a configuration and that gets played in your simulator/emulator tools using a PCIe transactor as shown below. The Mentor PCIe Transactor has a Direct Programming Interface (DPI) and Veloce Transaction Library (VTL) API:


    On the left-hand side are High-Level Verification Language (HVL) components that talk through the C Proxy layer and Extended RTL (XRTL) FSM.

    A second approach using UVM has data streaming to PCIe transactors or Bus Functional Models (BFM) from directed tests.

    UVM Topology in support of Emulation

    The downside of UVM VBV is that UVM is the test executor with SystemVerilog, and there isn’t a direct connection to SDN management SW. UVM VBV with an emulator is called testbench acceleration.

    Verification with Advanced VBV (AVBV) has the SDN DUT connected to the Software Development Kit (SDK) HW. The limitation here is that co-verification between product SW and HW is not provisioned. This methodology used with an emulator over IO is called In-Circuit Emulation (ICE).

    VBV issues from these three methodologies include:

    • Large Memory Mapped IO (MMIO) spaces create overhead
    • Slow simulation speeds

    To overcome the limitations there is a better way, and that’s with an approach using Virtual PCIe because applications can interact with the emulation DUT as if it was the actual silicon, enabling HW/SW co-verification. The SDN device will be operating slower in the emulator versus final silicon, but orders of magnitude faster than simulation, yet sufficiently fast for co-verification and debugging.

    Here’s an example showing a Virtual Machine (QEMU) running Linux, Red Hat or SuSE OS:

    VirtuaLAB PCIe3 Control and Data Path Overview

    VirtuaLAB is a virtual PCIe RC from Mentor, and the library already supports:

    • Networking
    • Multimedia
    • Storage
    • Automotive
    • CPU

    The PCIe Software Under Test (SUT) driver in this approach is identical to what a customer receives, so no more surprises between pre and post silicon.

    Now your engineering team with VirtuaLAB PCIe can take a parallel development path with product SW/drivers and HW, instead of a much-longer serial process waiting for silicon. Remember, with the AVBV approach you couldn’t test functional SW APIs, but they can be tested with VirtuaLAB PCIe. Some key features to know about with VirtuaLAB PCIe are:

    • Checkpoint save/restore
    • Protocol analyzer
    • Modeling flexibility
    • Advanced debugging

    One user compared this emulation approach versus a device on the bench, reporting that 15 seconds of SDK in real time took about 30 minutes in the emulator.

    All transactions between host and emulator are visible, making for quicker debug. There’s even a protocol analyzer that is similar in appearance to a LeCroy PCIe analyzer, providing statistics and tracing features:

    VirtuaLAB PCIe Protocol Analyzer

    Modern SoCs like SDN devices are incredibly complex in terms of verifying both HW and SW, and the traditional Vector Based Verification (VBV) methodologies can fall short. Using the newer, virtual methodology with tools like VirtuaLAB PCIe from Mentor are more productive. Read the complete 10 page White Paper here.

    Related Blogs

  • 3 Replies to “Verifying Software Defined Networking”

    You must register or log in to view/post comments.