UVM Can Kill You. More News At 11

Ok. I agree. Not a great title. I don’t like it either. Some pretty aggressive clickbait, I know. But it’s got the quick hit, newsy cliffhanger feel that makes you want to tune in anyway, doesn’t it?

I had to go for it.

For what it’s worth, it wasn’t my first choice. I wanted to go with “What You Don’t Know About UVM Can Kill You. More News at 11”. Same punch. Still the hint that there’s something big, if not ridiculous, here. And there’s the emphasis on what we don’t know about UVM and how it could really get us. A bit on the long side for a blog title though so I had to boil it down.

Actually, let me backup…

I boiled that down only after I realized I couldn’t use “The Size And Flexibility Of UVM Make It Impossible To Understand How It Can Kill You. More News At 11.” I wanted to emphasize how we accept it’s flexibility while disregarding the downside, namely the amount of UVM required to support it – we do it by picking one way of doing things and ignoring the rest.

So more information in that title is good. And we keep the imminent danger element which is why I like it.

Or should I say ‘liked’ it until I thought about how having one way of doing things sounds a lot like a usage model. A bit ironic, considering we pitch UVM as providing a single, universal usage model. Really, it’s a superset of usage models from which we weave together what makes sense to us. The complexity of the superset remains though, making it feel at times like we’re tying a jet engine to a wiener roast. It kind of works until it doesn’t – not to mention we can roast a lot of wieners fast – so how about “The Size, Complexity And Flexibility Of UVM Make It Impossible To Understand How To Create Usage Models That Won’t Kill You. More News At 11?”

That could fit.

But it’s still just part of the story.

Teams change over time. Long time members grow and mature. Maybe they move on. Teams add new hires who have worked within other usage models. Mix in a few new grads and suddenly we have teams of varying ability with a combination of ideas that are obsolete, old, maturing and new. Everything fuses together, for better and worse, complicating a team’s usage and making it hard to truly share a view of what it’s trying to accomplish. All that considered, we could have done something like “The Size, Complexity And Flexibility Of UVM Make It Impossible To Build A Universally Shared Understanding Making It Very Difficult To Create And Maintain Usage Models That Won’t Kill You. More News At 11.”

Better.

Whoa. Wait a minute.

I just remembered that usage models extend beyond teams. That’s the whole point of UVM. We can’t ignore how multiple usage models within an organization become intertwined. Or the fact IP providers have their own usage models. There’s also the competing usage models that emerge from within teams. It’s a jigsaw puzzle of a horse’s head on a hippo’s body with propellers for feet floating through space in a Ferrari; that and the pieces don’t exactly fit. Cobbling it together takes us to something like “The Size, Complexity And Flexibility Of UVM Make It Impossible To Build A Universally Shared Understanding Making It Very Difficult To Create And Maintain Usage Models That Are Productive And Coherent Between Teams, Organizations And IP Providers That Won’t Kill You. More News At 11.”

No? Not quite?

Ok. You’re right. Time to get serious about the consequences…

A proper title would need to be more realistic. UVM is pervasive in functional verification, but not to the point that it’s killing us. Obviously I added that for effect. And really, with only anecdotal evidence and so little hard proof for or against our standardizing on UVM, it’s probably better to speak in terms of probabilities than absolutes.

So one more crack at it…

“The Size, Complexity And Flexibility Of UVM Make It Impossible To Build A Universally Shared Understanding Making It Very Difficult To Create And Maintain Usage Models That Are Productive And Coherent Between Teams, Organizations And IP Providers Which In Turn Raises The Possibility, However Likely, That The Extra Overhead Incurred By Using UVM Might Damage Our Project Schedules And Products Instead Of Improve Them…”

Hmmm…

“…Until We Reconsider How UVM Is Pumped and Pushed As A One-Size-Fits-All Solution For Functional Verification And Relieve The Industry Peer Pressure That Implores Teams To Conform To Standardization That May Not Be In Their Best Interest By Providing Valid Alternatives Or, At The Very Minimum, Acknowledging That Valid Alternatives Do Indeed Exist. More News At 11.”

That’s it. Done.

Mildly… no… moderately depressing reality, a hint of impending doom, a sliver of optimism and the same news’y cliffhanger feel that I’m sure will have people tuning in. Really long, but who cares. That’s definitely the title I should’ve gone with.