0% found this document useful (0 votes)
210 views

Development of A Pcie Dma Engine Verification Framework: Michal Husejko Eda - Support@Cern - CH

This document proposes developing a PCIe DMA engine verification framework. It describes building blocks like the application I/O using a simple DATA+DAV+SYNC interface, an internal interconnect, and a PCI express block. It outlines a verification plan using SystemVerilog and UVM with virtual interfaces and scoreboards. Continuous integration is proposed using Git/GitLab for version control and Jenkins for regression testing, timing analysis, and building bitstreams. The framework is currently working with Git/GitLab and Jenkins driving QuestaSim simulation, and next steps are needed.

Uploaded by

svenka3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
210 views

Development of A Pcie Dma Engine Verification Framework: Michal Husejko Eda - Support@Cern - CH

This document proposes developing a PCIe DMA engine verification framework. It describes building blocks like the application I/O using a simple DATA+DAV+SYNC interface, an internal interconnect, and a PCI express block. It outlines a verification plan using SystemVerilog and UVM with virtual interfaces and scoreboards. Continuous integration is proposed using Git/GitLab for version control and Jenkins for regression testing, timing analysis, and building bitstreams. The framework is currently working with Git/GitLab and Jenkins driving QuestaSim simulation, and next steps are needed.

Uploaded by

svenka3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

Development of a PCIe DMA

engine verification framework


Michal HUSEJKO
[email protected]
Introduction
• About me:
– Working in the CERN eda.support
– I’m responsible for “Introduction to VHDL” course
available from CERN Technical Training Catalog
– I’m also involved in different IT projects
• Trying to stay up to date with (or learn):
– VHDL, tools
– SV+UVM
– Software development and Contiguous Integration
Typical data concentrator
• Many projects @CERN looks similar to this …
• FPGA device(s) inside data treatment pipeline
• Data IN ( could be SFP)
• Data OUT ( could be PCIe, or Ethernet or something
else)
• I was involved (2006-2009) in CMS/ECAL DCC project
– Did some basic SV+AVM
An experiment
• VHDL + Verification Environment + Project
Management/Build/Testing system
• VHDL
– PCIe DMA engine for FPGA
• Verification Environment
– SV + UVM
• Wrapped with …
– Complete software (and hardware) development
environment with Contiguous Integration (CI) setup.
Building blocks
• Application I/O
– In my example, I use a simple interface
(DATA+DAV+SYNC)
– Could carry some protocol like Ethernet
(IP,UDP,TCP)
• Interconnect
• System I/O
– Example uses PCIe, but could be exchanged to
Ethernet (1/10/40 Gb)
Some assumptions
• Stay vendor independent:
– No QSYS
– No EDK/IP Integrator
Layered Application I/O
• SFP transceiver used to transmit data
• Simple signaling:
– DATA + DAV ( packet length 1-512 Bytes)
– SYNC/TRIGG ( pulse + packet length 0-1 Bytes)
• TB
– Random: content, length, gap between packets,
presence of SYNC/TRIGG
– Predefined data patterns to help debugging
• Simulation
– Slower Sim: XCVR PHY + IP included
– Faster Sim: No PHY/IP, SV transaction model
Interconnect
• Internal Interconnect:
– Much simpler than Avalon-ST/AXI Streaming
– Independent Upstream + Downstream patch
– Each direction with DATA+CTRL (example 128b+110b)
– Cut-through or Store-and-forward operation mode
– Split bus protocol (MRd-CplD/Cpl, MWr, Msg [similar to PCIe])
– Channels switched with Deficit Weighted Round Robin (
Insolvency enabled )
• TB
– White box verification with assertions (signaling) and
scoreboards (packet level)
• SIM
– Only FIFOs components are vendor dependent
PCI express block
• Device Hard IP
– Altera Gen1 x8 ( i.e. Avalon-ST 128b@125 MHz if)
– In the future Gen2 and Gen3 (256b@250MHz)
• Split-bus protocol (many transactions in flight)
• TB
– Emulation of PC/ARM platform (buffers allocation)
• Involves getting many SignalTap snapshots.
– Split-bus packet (MRd -> CplD/Cpl) has to be handled with “real”
life latency and bandwidth.
• SIM
– Slow sim: Altera PCIe Verilog BFM wrapped with SVM+UVM
– Fast sim: TLP BFM (limited functionality/does not inject all the
“crap” seen with vendor BFM)
TB
• Interfaces:
– SFP
– PCIe
– I2C (sensors: I/U/T)
• SV + UVM
– VIP 1 – SFP RX
– VIP 2 – SFP TX
– VIP 3 – PCIe RX + TX
– VIP 4 – I2C
Basic verification plan (2)
• SFP TX:
– DMA CFG -> D:MRd -> CplD
-> D:MWr
– DMA RUN -> U:MRd -> CplD (DESC GET)
-> U:MRd -> CplD (DATA GET)
– Forward data (CplD) to SFP TX channel
– DMA DONE -> U:MWr (DESC DONE)
-> U:Msg (INT)
• How to distinguish between
Basic verification plan (2)
• SFP RX:
– DMA CFG -> D:MRd -> CplD
-> D:MWr
– DMA RUN -> U:MRd -> CplD (DESC GET)
Receive data over SFP RX channel
– DMA RUN -> U:MWr (DATA PUT)
– DMA DONE -> U:MWr (DESC DONE)
-> U:Msg (INT)
Git+GitLab
• Git
– Distributed revision control
– Lightweight branching and merging (compared to
SVN)
– Strong support for nonlinear development flow
• GitLab
– Self hosted Git management service (your very own
private GitHub)
– Source file viewing
– Forking projects
– Issue tracking/Wiki/Code snippets exchange
Jenkins
• Continuous Integration
– Regression testing
– Automatic feature verification (bottom line: your
TB has to be self-checking, waveforms only for
debugging)
– Timing analysis (Quartus/Vivado)
– Bitstream builds
– Many plugins (mainly around software
development)
Jenkins (xUNIT) + UVM
• How to use SV+UVM with Jenkins ?
– Good start is to use JUNIT capability available in Jenkins –
you need XML log file which follows JUNIT format
– Easiest way is to replace UVM reporting server with your
own one which generates XML log (already done by
Verilab, source code published)
– Write XSL schema to transform your custom XML into
JUNIT XML format.
– Your own XML + XSL can be feed into Jenkins’ xUnit plugin
which will feed JUNIT plugin automatically.
– From then on, you can use all reporting available in Jenkins
(error reports, trends analysis, etc.)
Summary
• What is working
– Git + GitLab server
– Jenkins + UVM XML reporter + QuestaSim
• Next steps
Learning resources
• Verification Academy (courses, videos, forum)
• Cadence UVM Book
• SystemVerilog for Verification, 3rd
• Verilab DVcon 2012 paper
• CIENA SNUG 2013 Jenkins paper

You might also like