1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest Research Institute San Antonio, Texas (210)

HowardMAPLD2005/193-W2 Background Verilog is a hardware description language for digital logic design (FPGA/ASIC/PLD) Typical usage –Design End item design description (RTL for synthesis) –Verification Modeling input interfaces (providing proper data/control relationships) Generation of test stimuli, esp. for low-level verification activities. Robust & simple first order DV with standard tools –Not adequate with growing complexity, multiple devices

HowardMAPLD2005/193-W3 Low-level Verification Results of this first order modeling are often verified by visual means –Finite limitation on the amount of transactions that can be verified visually Rudimentary checking of interface protocols in Verilog models –Repetitive pattern detection –Interface timing Verilog checkers increase verification capabilities tremendously –Directed tests are excellent for nominal function –Perfect for small number of scenarios It is at this point that the real strength of Verilog is revealed – the programming level interface (PLI).

HowardMAPLD2005/193-W4 The Verilog PLI The Programming Language Interface is a procedural interface between Verilog simulation and other software programs –Verilog models can invoke external program during simulation Accessibility to every attribute and capability to read and/or modify any value in the simulation –Initializing memories at simulation start –Verifying end of simulation results. C programs can be tied through the PLI to Verilog shell models –Dynamically generate test stimuli –Check design outputs –Scoreboard non-linear data flows –Incorporate random features

HowardMAPLD2005/193-W5 PLI Goal 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. –Recent experiences (what I had to learn in the customer’s lab) Flow Control from multiple sources is complicated to model in traditional hardware simulation FSW access order should not matter, but sometimes it does “Garbage in” can cause system problems outside the digital realm

HowardMAPLD2005/193-W6 PLI Advantages Simulations do not need to be limited –Time, complexity or randomness Extended to reflect the real world –“Software” interaction can be modeled More simulation cycles can occur –Designer does not verify test results, checkers and PLI do –Designer time spent on bug fixes Capability to randomize each test –Can mimic any scenario Coverage –Regression tests

HowardMAPLD2005/193-W7 Our approach PLI extension of FPGA verification capabilities –Incorporation of functional/GSE software Development of decode routine for turbo encoded data Development of several key bus functional models and PLI routines –Memory Initialization Large lookup table loaded in zero sim-time to PROM model –CPCI interface / software Working on control mechanism back to SW (ISR) –Export of telemetry Data provided to third party for verification Frames to be transferred to scoreboard for integrity check

HowardMAPLD2005/193-W8 Verification Environment Simulations for Command & Telemetry Board –All component models utilize worst case timing Board level timing verification –Verification of processor to local bus traffic –Verification of inter-FPGA local bus traffic

HowardMAPLD2005/193-W9 Board Verification Board GSE is designed to verify board level requirements. –Mixture of automated and manual measurements. Board Test Cases have been defined based on PFS –Basis for PLI functions IR&D funds for enhanced simulation environment –Three fundamental testing blocks: cPCI Telemetry RX Serial command TX

HowardMAPLD2005/193-W10 PLI Verification Environment cPCI –Memory peeks / pokes, config cycles, resets –Exhaustive memory tests, VTC duration testing, serial command verification, telemetry packet generation, 1553 traffic, access order dependencies, etc. Telemetry RX –ASM detect, de-randomization, frame length check –Frame integrity, FHP check, packet integrity, data integrity Telecommand TX –Inject telecommands, monitor response –Error injection, data integrity (PCI side)

HowardMAPLD2005/193-W11 Synergy Overall GSE scheme nearly identical to board level verification through PLI –Necessity to “cover” every function Wiggle every GPIO Address all memory locations Exercise each function –Data integrity checking through link listing mechanism Injected data is “scoreboarded” / exported data is then knocked out out of link list Minimal impact on GSE team to accommodate PLI functions

HowardMAPLD2005/193-W12 Status Two stage approach to PLI functionality Stage One (Complete) –Currently performing turbo encode, telemetry export, turbo decode (error detect only), and data integrity tests –Utilizing GSE generated PCI transactions without “oversight” PLI to GSE SW does allow conditional control as implemented Stage Two –Linking of PLI to GSE for conditional control –Use of scoreboarding mechanism to verify data integrity

HowardMAPLD2005/193-W13 Results Simulation run length not limited by designer attention –Scripting allows for “board” initialization and simulation setup Parameterized functional testing –Runs can be regressive or random –Results then used for debugging by designer Coverage metrics –Merge results from successive simulations –Generate directed tests for unexercised logic ACTUAL METRICS PENDING… I’m still working on Stage Two, and trying to bring up hardware in the lab!!!