"Reuse C Test and UVM Sequence Utilizing TLM2, Register Model and Interrupt Handler" - HongLiang Liu - Advanced Micro Devices, Inc.Author had system level tests written in C that used to target PCIe. They moved to AXI. The author demonstrates how he leveraged his existing test cases for the new bus protocol. Essentially, the existing PCIe layer was modified to send AXI packets via TLM to the AXI UVM UVC.
For interrupt handling, the author proposes use of UVM resource DB. Any UVM object or component can query resource (i.e. interrupt) and call wait_changed() on the resource handle.
"Engineered SystemVerilog Constraints" - Jeremy Ridgeway - Avago TechnologiesJeremy attempts to solve grand challenge problem of run-time modification of SystemVerilog constraints. He breaks down a SV constraint into CNF form and add pre-/post- fix terms (sorry, incorrect terminology) that can be modified at run-time. For example, query the coverage database, then update the constraint terms.
Theoretically, his approach is sound, but there is overhead in implementation. I was skeptical whether it could be used in a real project and spoke to Jeremy after the presentation. He is indeed using the approach in his small team.
My impression (not having tried to implement) is that the technique would substantially limit the user to a subset of what is supported by the SystemVerilog constraints language.
"Automated Performance Verification to Maximize Your ARMv8 Pulling Power" - Nicholas A. Heaton - Cadence Design Systems, Inc.I had high hopes for this talk, but it feel that it fell short. The author demonstrates how a "fake" testbench can be generated for the purposes of performance modelling. The agents can be confirmed for specific workloads. The agents are connected to CCI interface and (I believe) memory controller. Performance data is collected from the system during run time. Checks are done on the collected data, i.e. does agent 1 meet QoS requirements. It was hard to tell, but it seems that the methodology was for performance verification of the only the incorrect (CCI), not the full memory subsystem. I will need to read the paper.
"Design and Verification of a Multichip Coherence Protocol" - Shahid Ikram - Cavium, Inc.
This was interesting. The author describes his methodology for specifying cache coherence protocol in a table format. From his custom table format, he feeds the architectural spec of the coherence protocol to Jasper architecture modeling tool and does model checking. He also points in the direction of a free model checker called spin which I will definitely check out.
"Table-Based Functional Coverage Management for SOC Protocols" - Shahid Ikram - Cavium, Inc.
From the same tables, Cavium can generate assertions and functional coverage models. The automated approach allowed architects to very quickly iterate their coherence protocol.
"Randomizing UVM Config DB Parameters" - Jeremy Ridgeway - Avago TechnologiesThis was loosely related to Jeremy's first talk. It seems to be an earlier effort. He builds up his own constraint language based on SystemVerilog classes.
"Coverage Data Exchange Is No Robbery, Or Is It?" - Samiran Laha - Mentor Graphics Corp.This was a discussion about whether coverage data can be shared across tools. In my personal experience, it is a no. The author states that progress is being made and Mentor is committed to open standards.
"Standard Regression Testing Does Not Work" - Daniel Hansson - Verifyter ABDaniel gave was amounted to a marketing presentation. Pindown has an interesting value proposition.
"Advanced Usage Models for Continuous Integration in Verification Environments" - John Dickol - Samsung Austin R&D CenterJohn gave a good talk here. He gives three practical examples of a continuous integration system using Jenkins and GIT.
"Mining Coverage Data for Test Set Coverage Efficiency" - Monica C. Farkash - Univ. of Texas at AustinThe talk was a summary of Monica's PhD work. Results of a data mining exercise for CPU verification were given. Given a random test generation, associated scenario files and functional coverage, could any conclusions be drawn? Author was able to give with confidence that reducing the number of instruction per random test would not substantially reduce the amount of coverage collected.
I thought this was a very interesting talk. It would be interesting to collect some data from our random generators and do some visualization. It would also be helpful to begin to classify functional coverage points that are easy or not easy to hit. This information was considered in her analysis of the data.