Extending FPGA Verification Through the PLI

Extending FPGA Verification Through The PLI

Paper 193 Submission to MAPLD 2005

Charlie Howard, Senior Research Engineer, Department of Space Systems, Space Science and Engineering Division Southwest Research Institute 6220 Culebra Road San Antonio, Tx 78228 (210) 522-3788 [email protected]

SOUTHWEST RESEARCH INSTITUTE® Space Science and Engineering Division 6220 Culebra Road, San Antonio, Texas 78228-0510 (210) 684-5111 · FAX (210) 647-4325 1 Abstract Verilog is a hardware description language for the design of programmable logic, and is in widespread use throughout the electronics industry. It is used not only for end item design description, but also for modeling input interfaces and test stimuli during low- level verification activities. The results of this first order modeling are often then verified by visual means. There are however, significant limitations on visual verification. It is at this point that the real strength of Verilog is revealed – the programming level interface (PLI).

The PLI can be used to link any type of application to the simulation, providing access to every attribute within the Verilog simulation structure under program control. The capability to read and/or modify any value in the simulation gives flexibility to perform all simulation tasks, from initializing memories at simulation start to verifying end of simulation results. C programs can be tied through the PLI to Verilog shell models, allowing C programs to be used to dynamically generate stimuli or to check design outputs. In short, the PLI allows the designer to build a robust virtual test bench that allows the functional interaction of hardware and software to first be characterized without lab space.

Using the PLI, simulations do not need to be limited in time, complexity or randomness; they can be extended as necessary to reflect the real world. Many more simulation cycles can occur, and by incorporating the capability to randomize each test, an immense number of HW/SW interactions can be characterized for flaws. Using random and directed test techniques, functional verification of the logic design can be extended far beyond that which can be provided by using first order techniques. The resulting design is much more robust and likely to function when moved into silicon.

Within the current design cycle, SWRI has extended its FPGA verification capabilities, by developing several key bus functional models and PLI routines. Specific approaches and examples will be presented.

2 Introduction Over the last 25 years, Southwest Research Institute has made a substantial commitment to the development of advance computer systems for space. SwRI’s IR&D programs have been a major element of this commitment, consistently supporting the development of key technologies needed to compete for tomorrows space missions. The technologies developed using IR&D funding range from the first SC-1 space flight computer in 1979, to the recent PCI-VME Bridge (PVB) in 2001, and cPCI-to-local bus logic core in 2005.

One of the key technologies to SwRI’s spacecraft avionics is the use of Field Programmable Gate Arrays (FPGAs). FPGAs are electronic devices that contain the equivalent of tens to hundreds of thousands of logic gates (i.e. AND / OR gates, Flip Flops, etc.), which can be configured to meet the design needs. SwRI’s line of spacecraft computers utilize FPGAs extensively to provide advanced digital logic and processing capabilities to meet mission requirements. As an example, the SwRI Command and Telemetry Board, the Department of Space System’s flagship product, utilizes four radiation hardened FPGAs which have a total capacity of 288,000 logic gates each to meet the requirements for the Orbital Express, NPP and NextView missions. In the past FPGA designs have been simple enough that the designs can be created using normal schematic capture techniques. Today, however, FPGA designs have increased in size and complexity to require the use of Hardware Description Languages (HDLs) to “code” the FPGA in a manner very similar to software coding.

In keeping with the increase in design complexity and the transition from previous schematic capture techniques, the verification and validation of FPGA designs has become increasing complex and costly. Verification activities include code walkthroughs, simulations of each FPGA interface, and limited simulation of larger multi-FPGA systems. The accurate and timely verification of FPGAs for space flight programs is critical to meeting cost and schedule obligations, as well as ensuring the success of programs. In the last two years, the verification and validation of FPGA designs has become one of the most critical, and closely monitored items for NASA and DOD space programs. Several NASA programs are currently listing FPGA functionality as one of the top mission risks during mission reviews.

The traditional method of FPGA design validation is through low level simulations that address core functionality and interface protocols. Higher fidelity simulations are typically not practical due to the limits of the simulation environments and tool sets. More stringent testing is accomplished through the use of custom Ground Support Equipment (GSE) and complex test software. No clear method exists that can effectively couple the test software that is used for the laboratory testing and the simulation environment of the FPGA designer. This paper will explore the use of the Verilog Programming Language Interface (PLI) to bridge that gap and provide a direct link between these very different test environments.

Three major objectives have been established for this paper including: interface GSE test software directly to the logic simulation and design environment; provide a virtual design model that a software developer might use as the test platform prior to the arrive of actual engineering hardware; establish a standard interface protocol and methodology that will allow this capability to be extended through our spacecraft avionics designs.

The techniques developed in this paper will help to improve the fidelity and test completeness of our FPGA verification activities as well as establishing a full hardware simulation model to assist in post-delivery support and troubleshooting. The expansion and augmentation of space flight FPGA verification activities directly benefits the Institute by improving the final quality, reliability, and cost effectiveness of SwRI spacecraft computer systems. As the cornerstone of our spacecraft avionics, the design validity of our FPGAs is a fundamental concern that is gaining greater attention at the mission level. 3 Background – Verilog and Verilog PLI Verilog is a Hardware Description Language; an HDL is not software, but rather a textual format for describing digital electronic circuits and systems. Verilog is in widespread use throughout the electronics industry for the design of digital logic circuits, and in particular for programmable logic such as FPGAs. Tools are available from major EDA vendors to support the development of logic from concept through hardware. Verilog is used to describe the data flow and control of desired logic for an FPGA, thus creating custom logic. Verilog is also intended to be used for verification through simulation, for timing analysis, for test analysis (testability analysis and fault grading) and for logic synthesis. SWRI’s Department of Space Systems has standardized on the usage of Verilog to describe the data flow and control of desired logic, which can be synthesized into a programming file for an FPGA thus creating custom logic, and on the Verilog PLI for advanced simulation capabilities.

Verilog began as a proprietary hardware modeling language by Gateway Design Automation Inc. in 1984. It is rumored that the original language was designed by taking features from the most popular HDL language of the time, called HiLo as well as from traditional computer languages such as C. Cadence Design Systems purchased Gateway, and in 1990 decided to “open” the Verilog language to the public; in 1995 Verilog became IEEE Standard 1364.

The Verilog language was designed from inception to include a programming level interface (PLI), which allows invocation of external programs from the simulation environment. The IEEE standards for Verilog define a set of PLI functions that every Verilog simulator must support; these functions provide access to the simulator data structures. Among programmers, such a set of functions is generally referred to as API (Application Programmer Interface), that is, a set of functions that a program exposes so that programmers can customize it or write other programs that use it.

The PLI can be used to link any type of application to the simulation – custom output displays and user interfaces, debug utilities, hardware models, and C language models. PLI provides the capability to read and/or modify any value in the simulation and to access every attribute within the Verilog simulation structure. Typically, custom C or C+ + routines are written to provide higher levels of simulation control and data checking.

Verification of FPGA logic is typically done as part of a bottom up verification while each design progresses. By modeling input interfaces and test stimuli in Verilog, the behavior of the logic can be simulated, and then analyzed visually or by rudimentary data checkers. This methodology is robust, and any type of interface can be stimulated and checked, but there is a finite limitation on the amount of transactions that can be verified visually. Models written in Verilog that check interface protocols are highly useful for repetitive pattern detection and interface timing, and increase verification capabilities tremendously.

The PLI provides a way to create user defined system tasks and functions for manipulation of the simulation environment. When the user task is executed in the simulation, the defined C function is executed, reading and/or modifying values within the simulation in zero time. There is a complex methodology for implementing the schedule mechanism for each PLI “call”, but the PLI provides protection to the simulator’s data structure, while providing access to it. Through the PLI, user tasks may get and put any type of value into the simulation data structure.

Memories and arrays are Verilog objects which can be accessed through the PLI interface. For instance, a Verilog ROM model may be initialized at simulation start to hold calculated binary values for use as simulation progresses. Another PLI method is to verify data path integrity by displaying memory contents after writing a known patterns at the end of simulation.

By developing Verilog shell models, also known as bus functional models, C programs may be used to dynamically generate stimulus for a design, or to check design outputs. Checking capability is greatly increased from pattern recognition to any combination of validation (data integrity, communication protocols, etc…). Ideally, an overlying program could provide a scoreboard to verify the success of data passed from all sources to all destinations. The real strength of Verilog is not in it’s success as an HDL. The real strength lies in the PLI, which allows for building a virtual test bench. The functional interaction of hardware and software may first be characterized without lab space, real application software may be co-verified, test coverage of the logic design can be extended and simulations can be exhaustive.

Simulations do not need to be limited in time, complexity or randomness. By utilizing the PLI, many more simulation cycles can occur, and by incorporating the capability to randomize each test, an immense number of HW/SW interactions can be characterized for flaws. The simulation environment includes basic core elements such as bus functional models for common interfaces with accompanying PLI data handling routines. For an FPGA with a processor interface, a Verilog model is designed that provides the appropriate timing, control signals and interfaces. The model must also include the appropriate PLI system tasks or functions to allow “test software” to access design resources, such as reading and writing addressable resources.

Within the current design cycle for Kepler, SWRI has extended its FPGA verification capabilities, by developing several key bus functional models and PLI routines. Through the PLI, advanced encoding algorithms for telemetry are verified, hardware/software interaction is verified, and design integrity is extended through better code coverage. With the development of Verilog PLI capability, mission critical CCSDS command and data functions undergo more useful simulation cycles, allowing the Southwest Research Institute to provide the highest level of mission assurance yet delivered, while limiting software integration issues.

4 Applicability to FPGA Verification and Validation The traditional FPGA verification process has the FPGA designer performing incremental simulations of a design at increasingly higher levels of the design hierarchy. This “bottoms up” approach to FPGA verification starts with the creation of functional simulations of low-level design blocks (ie. Counters, memories, shift registers, state machines). As blocks are simulated and verified, they are incorporated into higher functional levels and tested per the overall requirements (i.e. accepting a serial command data stream and executing it’s contents).

The overall test fidelity is limited by the complexity of the test benches, their ability to mimic outside interfaces, and in particular, the inspection of large amounts of data. This is the limiting factor to the completeness and ability to provide a high degree of confidence to the verification of FPGA designs, and more dramatically FPGA/FPGA or FPGA/interface interaction. By developing Verilog shell models, also known as bus functional models, C programs may be used to dynamically generate stimulus for a design, or to check design outputs.

Checking capability can be greatly increased from pattern recognition to any combination of validation (data integrity, communication protocols, etc…). Ideally, an overlying program could provide a scoreboard to verify the success of data passed from all sources to all destinations. The Verilog PLI allows the test bench to interface and access C/C++ routines and functions, significantly expanding the capability of the simulation environment and increasing the flexibility of responding to test results, applying stimulus and simulating off-nominal conditions.

As an example, consider an FPGA providing a CompactPCI interface to a MIL-STD- 1553 bus (as seen on the Deep Impact, Orbital Express, and Kepler CTB modules). Traditional simulation test benches would provide a limited set of cPCI transactions to target reading and writing data to the 1553 bus. With the use of Verilog PLI, this simulation environment can be expanded to use the actual ‘C’ test code that will be run as part of the laboratory verification of the hardware and provide a much more comprehensive test with a wider variety of transaction combinations, sizes, data widths, etc. In essence, the Verilog PLI test bench is providing “virtual” hardware for the lab test code to execute against.

The key to utilizing the PLI effectively is to provide the time and tools necessary for development of the simulation environment. The environment includes basic core elements such as bus functional models for common interfaces with accompanying PLI data handling routines. The BFM provides the “physical” interface protocol, while the PLI routine manipulates the data. For an FPGA, board or system with a processor interface, a Verilog model can be designed that provides the appropriate timing, control signals and interfaces. The model should include the appropriate PLI system tasks or functions for “test software” to access design resources, such as reading and writing addressable resources. The PLI also allows connection to stand alone C programs, through sockets, enabling software development to progress unheeded by hardware verification.

Within the current design cycle, we have the opportunity to develop several key bus functional models and PLI routines to explore the power and true applicability to our hardware development processes. Development of this infrastructure is essential to providing defect free hardware as design size and complexity increases. 5 Project Objectives The latest feature for Kepler’s command and telemetry solution is the application of Turbo Codes to the serial telemetry stream. Currently, there is no method to completely verify the accuracy of the hardware implementation until the integration of hardware with GSE equipment and software. Through the PLI, we will be able to export data sets to both the GSE supplier, customer test group, and end-user (NASA) ground support groups to verify end to end compliance.

This project will establish two Verilog PLI “hardware/software” models, to establish a basis for all future cPCI and CCSDS telemetry systems. By establishing and proving this capability, SwRI has the opportunity to not only enhance the overall quality and reliability of its space avionics, but also further strengthen the Institute’s position as an industry leader in Spacecraft electronics design.

The expansion and augmentation of FPGA verification activities provides direct benefits by improving the final quality, reliability, and cost effectiveness of FPGA based spacecraft computer systems. As the cornerstone of spacecraft avionics, the design validity of FPGAs is a fundamental concern that is gaining greater attention at the mission level. “Latent” FPGA specification and design errors that are not caught during simulation or test, but found late stages of integration, result in cost growth to the mission as well as slipped delivery schedules. The techniques developed in this paper will help to improve the fidelity and completeness of FPGA verification as well as establish a full hardware simulation model to assist with post-delivery support and troubleshooting. The interface, modeling, and simulation capabilities of Verilog PLI developed with respect to the FPGA design process will assist in reducing the number of post delivery problems encountered and provide an even more cost effective solution for our customers.

The goal of this paper is to promote the use of the Verilog PLI as the key component of FPGA verification and validation and the basis for producing space qualified avionics. This will be accomplished by developing expertise using the Verilog Programming Language Interface (PLI) to assist in the verification and validation of space flight FPGA designs. The Kepler CTB will serve as the test bed for these activities by using its four FPGA designs (cPCI, telemetry, telecommand, memory control) as the units under test.

The specific program objectives include: 1. Interface GSE test software that will be used for the verification of hardware to the FPGA simulation environment using Verilog PLI a. Auto-initialize the ROM table for generation of the turbo coded telemetry b. Provide the capability to export telemetry in text form to verify implementation of turbo codes by GSE developer, customer and end-user 2. Produce a “virtual CTB” model that will allow test software to execute and access the CTB in simulation in the same manner as normal hardware in the lab. a. Link GSE/external test software with the cPCI BFM in the CTB system model to generate data for the telemetry downlink. b. Provide the simulation control mechanism to call external software and perform data integrity checks on injected data 3. Establish a standard interface protocol and methodology to extend this capability to all SwRI spacecraft avionics developments.

6 Technical Approach Functional simulation is accomplished by modeling interfaces and test stimuli in Verilog. The behavior of the logic (and stimulus) can be “simulated”, and results must first be analyzed visually. Verilog is also used to implement interface checkers, which include complete checks for interface timing. Models written in Verilog that can check interface protocols are extremely useful, but the functionality is typically limited to repetitive pattern detection. This methodology is robust, and any type of interface can be stimulated and checked, however, there is a finite limitation on the amount of transactions that can be verified visually when the data stream is pseudo random.

The Verilog language was designed from inception with the capability to read and/or modify any value in the simulation and to access every attribute within the Verilog simulation structure. Manipulation of the simulation environment is done by linking C functions and tasks directly into the simulation environment. The PLI provides a way to create user defined system tasks and functions. When the task is executed in the simulation, the user defined C function is executed, reading and modifying values within the simulation in zero time. In essence, the Verilog simulation is the “main” program, and schedules all tasks, including those which are user defined.

There is a complex methodology for implementing the schedule mechanism for each PLI “call”. There are four routine types for scheduling function calls within the PLI – compiletf, calltf, sizetf, and simulation callback, each of which can be associated with a user defined system task. Before simulation time starts, sizetf defines the return value for the C call, and compiletf is used for syntax and usage checks. The calltf and simulation callback routines are used to schedule actual user tasks. The Verilog PLI provides protection to the simulator’s data structure, while allowing access to it.

Each simulation object and event has a unique handle, as does each attribute of an object, which can be accessed in the manner of traversing a linked list. By traversing the linked list, user tasks may get and put values into the simulation data structure. Memories and arrays are Verilog objects accessible through the PLI interface. For instance, a Verilog ROM model may be initialized at simulation start to hold calculated binary values for use as simulation progresses. Another method is to verify data path integrity by displaying memory contents after writing a known pattern.

By developing Verilog shell models, also known as bus functional models, C programs may be used to dynamically generate stimulus for a design, or to check design outputs. Checking capability is greatly increased from pattern recognition to any combination of validation (data integrity, communication protocols, etc…). Ideally, an overlying program could provide a scoreboard to verify the success of data passed from all sources to all destinations. The real strength of Verilog lies in the PLI, which allows for building a virtual test bench, upon which real application software may be co-verified. The functional interaction of hardware and software may first be characterized without lab space, without power supplies and cables, without even buying parts!

6.1 Implementation Stages This IR&D will establish Verilog PLI “hardware/software” models, to provide a basis for all cPCI and CCSDS telemetry systems.

6.1.1 Turbo ROM Initialization The capability to import text file of turbo code pseudorandom coefficients, and initialize the Verilog EEPROM model at start of simulation (zero time) will be developed. This includes determining appropriate format for the imported data and the associated calltf routine to init the memory array.

6.1.2 cPCI Bus Interface For the cPCI interface, the approach will be to determine the subset of the CTB test procedure and software which should be re-used for basic reads and writes, and the routines to build packets for the three telemetry channels.

6.1.2.1 CPCI Indirect Use of GSE Code Initial use of the GSE code is done through an indirect method, without passing control and branching capability to the GSE software. This is accomplished through utilizing the GSE command log, which has a format compatible for compilation as a Verilog include file.

6.1.2.2 CPCI Direct Use of GSE Code The PLI routine will be developed with a “layered” approach, starting with the basic read/write and adding in complexity. The current PCI bus functional model will be enhanced with the “hooks” for the PLI calls. The methodology to pass simulation control to the C code shall be developed. Initial use of the GSE code is done through an indirect method, without passing control and branching capability to the GSE software.

6.1.3 Telemetry Interface The telemetry bus functional model will be enhanced to provide PLI access to export the received dataset to a file on a frame by frame basis. SWRI will develop a C program to decompose and check the turbo coded data. Optimally, this will be done dynamically, but the initial implementation will be to parse the file noted above.

6.1.3.1 Telemetry Export Initially, telemetry checking will be implemented utilizing a static methodology. The capability to export telemetry to a text file as binary ASCII will be developed. Two identical telemetry streams will be exported, one with turbo-coding enabled, one without. Turbo decode capability with error detection will be provided through a stand-alone C program, which will also compare the decoded telemetry with the control.

6.1.3.2 Telemetry Parsing for use of GSE Code There will be some significant modifications to the telemetry BFM and turbo decoding algorithm to allow re-use of the GSE code. The initial impetus will be to allow frame by frame turbo decode, which will require the management of simulation control and array pointers between simulator and C program. The final step will be to develop the use of sockets to transfer the frames to the GSE software for post processing.

6.2 Top Level Verification Once the key pieces are in place, the score boarding capability designed into the GSE software will also become part of the Verilog simulation. The functional “software” control typically exhibited at the cPCI interface will be available through the PLI – from low level peeks and pokes, to “packet” submission for telemetry download. Telemetry packet data is added to a linked list, and held for verification against data decomposed from the telemetry. By leveraging the score board capability of GSE software, the FPGA designer gets frame verification and data integrity checking “for free”.

By utilizing random and directed techniques coupled with the PLI enhanced simulation environment, the FPGA designs may then undergo an exhaustive number of simulation runs. 7 Results Functional simulation is accomplished by modeling interfaces and test stimuli in Verilog. The behavior of the logic (and stimulus) can be “simulated”, and results must first be analyzed

7.1 Implementation Results

7.1.1 Turbo ROM Initialization A C program has been developed to convert a series of coefficient values from a spreadsheet into formats useful for simulation and programming of the actual hardware. The PLI routines to implement initialization were created, then later replaced by the readmemh construct available through the Verilog 2001 standard.

Implementation of the coefficient table exposed two different logic flaws. First, a value that was intended to be held in a register across a sequence of reads was overwritten due to a missed term in the write enable equation. Second, the original set of coefficient values were all off by one; the hardware implementation required values from 0 to n, rather than 1 to n + 1. This problem was illustrated by an access to an uninitialized memory location and the ensuing propogation of the X output.

7.1.2 cPCI Bus Interface For the cPCI interface, the approach will be to determine the subset of the CTB test procedure and software which should be re-used for basic reads and writes, and the routines to build packets for the three telemetry channels.

7.1.2.1 CPCI Indirect Use of GSE Code The GSE command log has a format which is compatible for compilation as a Verilog include file. A short script comments out the timestamp data in each logfile, replaces a sequence of polling operations with a Verilog task for polling, and saves the result to a desired filename. Each simulation run requires a module compile to pick up the new sequence of GSE “commands”.

This method required a change to the GSE software command logging routine, which was accomplished and verified in about 45 minutes.

7.1.2.2 CPCI Direct Use of GSE Code The methodology to pass simulation control to the C code is under development.

7.1.3 Telemetry Interface The telemetry bus functional model will be enhanced to provide PLI access to export the received dataset to a file on a frame by frame basis. SWRI will develop a C program to decompose and check the turbo coded data. Optimally, this will be done dynamically, but the initial implementation will be to parse the file noted above.

7.1.3.1 Telemetry Export Data has been exported to ASCII text in binary format, and as hex after framing against the sync pattern. The turbo decode and error detect algorithm is underway. The exported data is available to the GSE hardware provider to cross verify their turbo decoding algorithm.

7.1.3.2 Telemetry Parsing for use of GSE Code The modifications to the telemetry BFM and turbo decoding algorithm will be initiated after completion of the static file based C code.

7.2 Top Level Verification There is a desktop machine and a simulator license available for around the clock simulations once the key pieces are in place. Several scripts will be developed to configure the simulation runs and collect and parse logfiles. By utilizing random and directed techniques coupled with the PLI enhanced simulation environment, the FPGA designs may then undergo an exhaustive number of simulation runs. Accumulation of coverage and bug logging will done as part of the top level verification. 8 Conclusion There remain only two key verification elements to completely verify the entire board: serial telecommands and the interrupt service mechanism on the cPCI interface. The steps to implement the elements into the simulation become trivial after completing the PLI capability to flow and verify data from the cPCI interface through the telemetry stream. Whether these last elements are completed, the experience gained and methodologies developed will provide the keys to fault free cPCI and CCSDS based hardware developed by SWRI.