Methodology Vs. Problem-Solving

When I was 18, I bought a Vespa ’67: the famous Italian scooter. It was already very old then, totally beaten-up, but luckily I had a friend who owned an auto-repair shop, and he was kind enough to give me some access at night.

For several weeks, I taught myself the art of metal bodywork, ending up with a beautiful metallic sky-blue ‘67 Vespa. God, I loved that machine!

Then one day, I began to hear strange voices from inside the engine. This kicked off several weeks of nighttime debugging. I would wait for the auto shop to empty out, then I would disassemble the scooter, break it down into its parts, trying to find the problem. But I had a rule: always reassemble it before dawn breaks and take it out of the shop.

This was my first real engineering job. I had no fear, and I simply knew that I could understand how it worked and fix it, simply by debugging. Nor did I think it might be worthwhile to read the spec and bank some knowledge before starting. I became so good at disassembling a Vespa’s engine that I think I could still do it today – and faster than most people. After all that, I ended up replacing a one-dollar metal pin, and I fixed the problem.

Sky-Blue Vespa from the 1960s

Today I’m a verification engineer, leader, teacher, and I lead Vtool, a company that invented the Cogita debugging platform.

When it comes to engineering, there is always a tradeoff between going step-by-step, using well-defined and proven methodologies, and exploring your own path, looking at problems as if for the first time, finding the best solution you can think of.

Take Universal Verification Methodology, or UVM, for example. Most of us had forgotten that UVM is actually (or almost entirely) e Reuse Methodology (eRM) developed some 15 years ago, mostly in Israel, where the main verification challenge at the time was large communication ASICs. The methodology had evolved over time, first to incorporate the emerging SystemVerilog language (OVM) and then to UVM that was supported and pushed by all major EDA vendors.

UVM is a well-known, highly used methodology, and, as such, it has many advantages. The very fact that people can speak the same language when it comes to verification planning and implementation is a big plus.

UVM Architecture example – why are these always so simple?

Methodology, any methodology, has another advantage. It makes weaker engineers more efficient, faster. If you are a genius who works alone, you will solve a given problem on your own without the need for methodology hanging over your head, limiting your creativity. But if you are an organization with hundreds of verification engineers, some beginners and some simply not the brightest, you need the UVM torch to light the way.

Recently, I came across one of the only large organizations I know that defied UVM, developing large and complex verification systems using their own methodology. It simply was built better for the design types and challenges they faced. I think they developed a good methodology, but further I liked the fact they had actually thought about it. When I teach verification in Vtool, be it to our new engineers or to university students, I try to encourage people to look at problems from a fresh perspective every time and come up with new ways to solve them. In the end, much like that young boy, determined to fix his beloved Vespa, you have to bring enough creativity and passion to the process in order to really scare these bugs away.