1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest...

1

Extending FPGA Verification Through The PLI

Charles HowardSenior Research Engineer

Southwest Research InstituteSan Antonio, Texas

(210) [email protected]

mailto:[email protected]

Howard MAPLD2005/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


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).


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


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


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


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


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

uP to LB FPGAMemory Control FPGA

Telemetry FormattingFPGA

Serial Command ProcessorFPGA

Downloadable

Memory

Health &StatusFIFO

VC1

VC0,2

SC FIFO

ScratchMemory


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

Monitor PC

DUT

Digital I/O

Single ended Analog Out

MIL-STD-1553B

Break-Out Box

O-Scope

Board Level GSE PC

Engineering Development Chassis

LL

DC

HL

DC

(Bin

ary

)O

utp

uts

32 Bi-Level Inputs

16 GSE Bi-Level Outputs

Serial UARTInterface

Resets (3), VTC_LTCH

MIL-STD-1553B BC / RT

SBC Based

Tests:

1. RegisterAccesses /

Interrupts

2. Scratch

Memory Test3. Downloadable

Memory

4. 1553 Shared

Memory5. H&S FIFO

6. A/D Validation

Power Supply

+28V,+7V

Eth

ern

et

Ethernet

Analog Inputs 16 Single Ended

Ba

ckp

lan

e (

PW

R),

Sta

nd

ard

Bu

s

COTSSBC

Differential Analog Out Analog Inputs 8 Differential

Serial commands

Telemetry:Parse & decode

Serial commands: Primary /Secondary / GSE

Telemetry: Carrier, Sub-carrier,GSE

GENERIC HW VERIFICATION SETUP


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)

Scoreboard

DUT(BOARDSIM)

Digital I/O

MIL-STD-1553B Summit /Shared Memory

BFMs

LL

DC

HL

DC

(Bin

ary

) O

utp

uts

32 Bi-Level Inputs

16 GSE Bi-Level Outputs

Serial UARTInterface

Resets (3), VTC_LTCH

MIL-STD-1553B BC / RT

PL

I

PLI

A/D Digital Interface

Vir

tua

l B

ackp

lan

e

VirtualProcessor

A/D (Digital model)

Telecommands

Telemetry

Telecommands: Primary /Secondary / GSE

Telemetry: Carrier, Sub-carrier,GSE

SIMULATION VERIFICATION SETUP

“Processor”Based Tests:1. cPCIAccesses /Interrupts2. ScratchMemory Test3. DownloadableMemory4. 1553 SharedMemory5. H&S FIFO6. A/D Validation


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


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


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!!!

1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest...

Documents

Transcript of 1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest...