Why I stopped “writing” RTL

Don’t get me wrong, I still create RTL, I just don’t “write it” anymore. OK, most of it anyway. I stopped “writing it” because I can’t hide from verification engineers.

When I looked at my customers, they were mostly EDA tools. The only time another engineer ever looks at my code is when I pull them into a review. Truth is, I’d rather they just reviewed my architectural specification and made sure my approach was solid. They’d probably prefer that also. Anybody wake up on Monday morning thinking, “Oh great! I get to review someone else’s code today.”?
Most of my customers change my code into something else. Again, nobody really wants to see my code. They’re happy with the new format. That is, until something bad happens. That’s when everyone wants to review it. Now that my code is under attack, I don’t want to show it to anybody. I just want to fix it quickly and silence my critics.
Seasoned engineers fly under the radar by creating code with reasonable area, timing, power and testability. All the stuff EDA tools can produce in volumes. Some tools give you a quick peak at what the code is going to look like on down the tool chain before you have to show it to anyone. Great stuff! Why can’t I hide from Verification engineers? It’s their life’s work to find something wrong with my precious code.

I spent some time thinking about verification engineers and what they really want from me. They convert my code into a seemingly infinite set of signals that only I can decode on a huge display (or two). It’s all gibberish to them. If I let them watch me decode it, they’re all the more convinced I have no idea what I’m doing. Verification engineers call them “bugs” and put descriptions of them in bugzilla for everyone to see; I call them “corner cases” . Still, nobody wants to see my code.

So I decided to give the verification guys what they really want: a functional coverage model in a nice neat package they could attack instead of my code. This solves two problems: first, they’re focused only the design intent model, and second, when the model is covered, they can go away and pester someone else satisfied with the knowledge that everything I gave them is working properly.

So I started a business and created an EDA tool to generate the code and the functional coverage model from one source. That source being the timing diagrams and flow diagrams I include in my architecture specification. Solid Oak’s CoverAll generates RTL, assertions, path coverage, test bench templates and formal scripts from those same diagrams. Now the playing field is leveled. The verification engineers can find “corner cases” in my design intent and I can find “holes” in their testbenches. It’s a win-win.

Jim O’Connor
Solid Oak Technologies

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>