Wednesday, March 4, 2015

Report from DVCon 2015

I attended DVCon over the past two days.  It was my second time attending.  I took some notes while I was there which I (quickly - excuse poor sentence structure) summarized below.  Keep in mind that these notes are preliminary and are based on presentations alone.  I have yet to read any of the papers.

"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 Technologies

Jeremy 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.
"Table-Based Functional Coverage Management for SOC Protocols" - 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.

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 Technologies

This 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 AB

Daniel 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 Center

John 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 Austin

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

"PANEL: SystemC –– Forever a Niche Player Or Rising Star of Chip Design?"

My recap: until someone starts real paying money for SystemC, it will remain a niche player.

"Coverage Driven Generation of Constrained Random Stimuli" - Raz Azaria - Cadence Design Systems, Inc.

Another unfortunate marketing presentation.  The author attempts to solve a grand challenge problem, can coverage data steer constraints... using Specman.  He did not clearly address the problem of how to correlate coverage data to a random variable.

"Navigating the Functional Coverage Black Hole: Be More Effective at Functional Coverage Modeling" - Paul Marriott - Verilab, Inc.

Paul presented practical advice for functional coverage planning, reviewing and modelling.  I had to leave half way through one, but I am looking forward to reading the paper.

Wednesday, February 25, 2015

Wednesday Night Hack - Next Two Months

I'll be busy in my spare time for the next 9 weeks.  I decided to sign up for MITx course: "Introduction to Computational Thinking and Data Science".  The cost for verified certificate track was a donation of $50, for which I did not mind paying whatsoever.

Here is the list of lecture topics.  It should be fun!!

  • Plotting
  • Simulations and Random Walks
  • Probability
  • Stochastic Programming and Hashing
  • Monte Carlo Simulations
  • Using Randomness to Solve Non-Random Problems
  • Curve Fitting
  • Knapsack Problem
  • Graphs and Graph Optimization
  • Machine Learning
  • Statistical Fallacies
  • Research videos

Thursday, February 19, 2015

TBT - Run Scener Run (2000)

Again, a collaboration with Joseph Mocanu from 2000.

Though, in fairness, he did most of the heavy lifting on this one.  I missed out on most of (but not all) my frosh week at Ryerson while working on this, totally worth it, lol.  Thanks to Andy Voss for capturing.

Wednesday, February 18, 2015

Wednesday Night Hack #11 - Experimenting with PyEDA

Not much updates lately.  Work and life are good.  I have probably been working on this for about 2 weeks.

Here is a short write up on an experiment I did using PyEDA for the purpose of developing a "poor-man's" random constraint solver using Python.

At it's core, PyEDA is a library that provides support for the specification of complex boolean functions.

It provides a very clean interface to PicoSAT, a popular SAT solver.

The first realization I made was that PyEDA did not support integer values.  With the help of the author of PyEDA, the following solution was devised.

You can specify integers using function arrays :

class Int:
    def __init__(self, name, width=3, value=None): = name
        self.width = width
        if value != None:
            self.farray = int2exprs(value, self.width)  # a real value
            self.farray = exprvars(name, width)  # empty variables

A function is array is nothing but an array of boolean variables.

The next step is to add operators.

    def __eq__(self, other):
        name = "{}eq{}".format(,
        f = Int(name, self.width)
        f.farray = farray([Equal(i, j) for i, j in zip(self.farray, other.farray)])
        return f

    def __add__(self, other):
        sum, carry = ripple_carry_add(self.farray, other.farray)
        name = "{}add{}".format(,
        f = Int(name, self.width)
        f.farray = farray([i & ~(carry[-1] & carry[-2]) for i in sum])  # this is completely incorrect, need to fix overflow issue
        return f

A wrapper to the SAT solve function call and a __str__ method :

    def satisfy_all(self):
       return self.farray.uand().satisfy_all()

    def __str__(self):
        return + " : " + str(self.farray)
Finally, we need a way to convert the result from the SAT solver back to our Int class.

    def from_soln(self, soln):
        value = 0
        for boolvar in sorted(soln.keys(), reverse=True):
            tmp = str(boolvar)
            if tmp.startswith(
                value = value | (int(soln[boolvar]) * pow(2,int(tmp[-2])))
        return value

I'll conclude this knowledge share post with 3 simple examples :

1. A == B

This works very well.

>>> a = Int('A', 3)
>>> b = Int('B', 3)
>>> f = (a == b)
>>> for soln in f.satisfy_all():
>>>     print("a="+str(a.from_soln(soln))+" b="+str(b.from_soln(soln)))
a=0 b=0
a=4 b=4
a=2 b=2
a=6 b=6
a=1 b=1
a=5 b=5
a=3 b=3
a=7 b=7

2. F == (A + B)

This works well, but there is an overflow bug that I have chosen not to fix.

>>> a = Int('A', 3)
>>> b = Int('B', 3)
>>> f = Int('F', 3)
>>> g = (f == (a + b))
>>> for soln in g.satisfy_all():
>>>     print("a="+str(a.from_soln(soln))+" b="+str(b.from_soln(soln))+" f="+str(f.from_soln(soln)))

a=0 b=0 f=0
a=0 b=4 f=4
a=0 b=2 f=2
a=0 b=6 f=6
a=0 b=1 f=1
a=2 b=6 f=0 <-- overflow bug

2. F == (A + B), F == 3

The same overflow bug happens here, but I also identified a more serious issue.  Since F is kept constant, the SAT solver does not return it's var.

a = Int('A', 3)
b = Int('B', 3)
f = Int('F', 3, 3)
g = (f == (a + b))
for soln in g.satisfy_all():
    print("a="+str(a.from_soln(soln))+" b="+str(b.from_soln(soln))+" f="+str(f.from_soln(soln)))

a=0 b=3 f=0 <-- f is not returned by SAT solver
a=2 b=1 f=0
a=1 b=2 f=0
a=4 b=7 f=0 <-- overflow bug

This concludes my experiment with PyEDA.  It was an worthwhile and interesting experiment, but it's time to move on.

As far as "poor-man's" constraint solver goes, this doesn't come close.  I would point interested individuals to the CRAVE project (or, commercial tools!).

Wednesday, January 28, 2015

TBT - Feedback. (2001)

From my days as a graphics programmer (OpenGL/win32) for the demoscene.  It was a collaboration with Joseph Mocanu.