FunCov is a user friendly, web-based tool that enables functional coverage model crowdsourcing for commonly used industry protocols. It’s my latest side-project/Wednesday night time suck and I’m excited about it. I’ve been working on it since August. It’s almost ready to go.

As much as people talk about our dependency on functional coverage, I believe usage lags far behind the rhetoric. Systemverilog language constructs are awkward and sporadically used by developers. That makes building functional coverage models cumbersome and error prone. Accessibility is also an issue where design engineers are completely shutout of the process. FunCov is designed to address these shortcomings. It’s a tool anyone can use, the IP you get out is exactly what you need and the code works. (I’d say I’m trying to put the fun in functional coverage but taking the frustration out is probably more accurate 😉 ).

Here’s a current snapshot of the home page…

I believe FunCov fills a void in current development methodology and I’m using lean startup to test that assumption.

Lean Startup

(I’ll preface my bit on lean startup by clarifying I’m no expert. My license to talk about it comes from book learning, a few conversations, a couple of conference talks and hands-on experimentation. If you’re new to lean startup and you’re looking for the lowdown from the real expert, I’d recommend the book)

Lean startup is an empirical method meant to enable rapid learning. You develop a hypothesis around your ability to meet some need of a particular market, then design an experiment that tests the hypothesis. The experiment involves rapidly iterating and releasing a product based on a series of assumptions. Validating your assumptions is done through gathering and analysis of usage data. In short, lean startup is a way to validate product ideas and assumptions as quickly as possible using the minimum effort possible. Based on real data (evidence), I decide whether to kill product ideas, iterate on ideas or pivot toward entirely new ideas.

The 2 lean startup tools I’m using are called a lean canvas and a minimum viable product (MVP).

Lean canvas is a single page write-up that captures a product assumption, solution and metrics for validating your assumption. There’s a task that your user is trying to accomplish, a specific pain point they incur in completing this task and the joy you intend to provide with a new solution. There’s a brief description of the solution. The most important part, to me, is the metric used to validate the solution. There are also sections to detail the value of the solution, it’s usability and the feasibility of you building it. All that fits on 1 page.

Here’s my lean canvas for FunCov. By the fact it captures my entire idea very concisely and it took about 30min to write, I’d say lean canvas fits the bill for kicking off this kind of effort.

Now onto MVP. An MVP is a version of your product that let’s you test your most important product/market assumptions using data from real users. It may not be pretty; it’s almost guaranteed to be incomplete; but it’s enough and the feedback helps mold future versions the way thinking really hard can’t. The opposite of an MVP would be a complete product that includes all the bells and whistles you’re assuming users will be screaming for. Of course the risk of building the complete product is that it’s all or nothing; there’s the chance your vision doesn’t match market need and all your time and effort is sunk building a big fancy thingamajig no one cares about.

I have an MVP for FunCov that delivers the ability to generate default functional coverage models for ARM AMBA interface protocols. It includes a fraction of the complete feature set I visualized when I started (i.e. adding custom ports, cross covers, transitions and sharing), but to me it meets the criteria of being minimally viable because it solves a small part of the problem while giving people a sneak peek into the entire solution (I’ll talk about the metrics I’m using to declare success near the end).

Story Mapping

I’m using story mapping for the first time. This is an agile software technique teams use to visualize interactions with a product. The lights around story mapping, coincidentally, also went on during Agile2015 so I can refer you back to my conference report for some of the theory. For the practical, this is a picture of what I have up beside my desk in my basement…

 

 

 

The blue stickies across the top are the main tasks my users can accomplish using FunCov. They are: account actions, new covergroup, coverpoint building, covergroup actions and exit actions. The yellow’ish stickies under the blue are the specific actions possible in each category. For example, ‘register for an account’ and ‘login to my account’ are 2 possibilities under account actions. Similarly, ‘start a new covergroup’, ‘load an existing covergroup’, ‘delete an existing covergroup’ amoung others are possibilities under the new covergroup actions. The yellow stickies near the top of the story map are what’s in my first release (i.e. MVP). The stickies near the bottom are on the todo list for subsequent releases.

Language and Web Frameworks

The other interest here is web development which takes me to the technical side of things. Aside from writing simple html, I have no experience with web development. Nada. So I needed a simple framework based on a language I already know. Out of the many possibilities, I narrowed it down to Django and Python with Bootstrap for the styling.

I won’t go into Django in detail, but I will say that if you doubt your ability to put together a simple web application just because you’ve never done it before, think again. Django, and I’m sure others, make building a web application easy peasy. You get a head start with registration and authentication, page templates, database interaction and almost everything else to the point where you’re left to focus on what you want to build instead of reinventing the internet. Likewise for Bootstrap. I did a little bit of customization, but pretty much all the FunCov styling is stock Bootstrap.

Success Metrics

If you read through my lean canvas, you’ll see the hypothesis in the metric section is:

We believe engineers are looking for an easy-to-use coverage solution so over a month period we’ll measure conversions of sign-up to covergroup generated. We’re right if 50% generate output.

To be clear, the experiment is successful if half the people visiting FunCov go all the way through the process and generate a functional coverage model. I think 50% is a great indication that FunCov fills a real need and getting there means I’ll be excited and carry on. Lower than 50% I’ll likely persevere regardless (since part of this is the experience of building a web application), and design a new experiment for the next new features.

Availability

This has been a fun project so far. Lots of learning in exactly the areas I was hoping for. As for the current state of FunCov, an MVP and announcement are imminent. Failure and lessons learned are guaranteed to follow!

Finally

A final point as to why I’m being public about this… I think we all understand web based tools are future – for some industries they’re already the present – but uptake in EDA has been slow to say the least. Part of the reason I started down this path was because I saw Victor Lyuboslavsky take a chance in building EDA Playground as a web based IDE. He invested a ton of effort to fill a need with a web based application in a way that was ignored by everyone else. I think that’s cool. I think it’s a precedent that people shouldn’t overlook. It also made me think it’s the type of thing that giant companies or other normal people can do (i.e. me… maybe you, too).

So here we are, and maybe it encourages the next person to get going.

If functional coverage, massive product failures, web application or lean startup experience are your thing, stay tuned. Regardless of how it turns out… good, bad or ugly… it’ll be public.

-neil