They Just Don't Get It

I'm on the "Verification Horizons" mailing list from Mentor Graphics.  Today, one of the items caught my attention.  It was a link to an article entitled It's a Matter of Style: SystemVerilog for the e User.  The article describes how, given the lack of AOP in SystemVerilog, a user can implement some of the features available in Specman.  Technically speaking, they are exactly correct.  Anyone using SystemVerilog (especially if you're used to using e) should read the article and follow the recommendations.  However, the conclusions they draw - namely that there is either no difference between SystemVerilog and e or that SystemVerilog is inherently better - are completely false! 

I can't believe that anyone at Mentor has ever written a serious testbench in e.  The article deserves a point-by-point analysis which I don't have time to write up at the moment.  I'll give it a shot over the next week or two.  In the meantime, check out the article, and let me know what you think!


The Meaning of 'e'

I consider myself reasonably knowledgeable when it comes to the 'e' language, but a question from a reader a couple of weeks ago asked a question that I really had never thought too much about before.  He wanted to know what 'e' signified - in other words, what the heck does that letter 'e' mean?  Mike Stellfox from Cadence was kind enough (as usual) to provide the answer:

When Yoav (founder of Verisity and the main inventor of the e language), came up with “e”, his idea was “English minus minus” (as opposed to C++).  The idea was to create a language that would allow verification engineers to more concisely describe their verification environment in a more English-like and declarative way.  It might be arguable how “English-like” e really is, but you probably get the idea of the analogy when you consider how declarative the language is in the following areas:

  • Declarative constraints
  • Declarative coverage
  • Declarative temporals

Thanks Mike, and thanks to the reader who asked the question!


History of the 'e' Language

A couple of months ago some of my colleagues at Verilab and I were discussing Aspect Oriented Programming and the e language and started wondering exactly how and when they came into existence.  Luckily, Mike Stellfox over at Cadence was able to give us the inside scoop directly from Yoav Hollander, creator of the e language, former CTO of Verisity, and currently the Verification Division Chief Technology Officer at Cadence.

Continue reading "History of the 'e' Language" »


IEEE 1647 Becomes a Standard!

Well, it's almost official - according to the IEEE 1647 web site from a post dated March 29, 2006:

RevCom recommends to approve the 1647 draft standard
In its meeting today, RevCom decided to support the approval of the draft standard. The IEEE Standards Activity Board is expected to ratify this recommendation tomorrow, at which point the draft will become an official IEEE standard.

So the e language finally becomes a standard... it's not likely that anyone except Cadence will be providing support for e anytime soon but perhaps it will provide incentives for folks to start developing applications that can work with Specman/e.  It would be interesting to see Cadence release an open-source version of Specman (or at least a stripped down version) that could be used to seed a potential community of EDA developers who could build a market around e related products and services. 


Switching from AOP to OOP - Strategy and Factory Patterns

I started my verification career using Specman.  As such, I have a pretty good understanding of how to design a verification environment using e and Aspect Oriented Programming (AOP) techniques.  Over the last couple of years I've been building my expertise in strictly OOP based environments such as C++, SystemC, and Vera.  It's been a bit of a struggle, as AOP makes rapid prototyping of a test environment a piece of cake (relatively speaking).  The reason is that AOP allows the creation of cross-cutting concerns that can be applied after the fact to allow the user to modify very specific portions of a data structure.

Continue reading "Switching from AOP to OOP - Strategy and Factory Patterns" »


A SpecManiac's Take on Vera

At Verilab we have consultants who are experts in all sorts of languages used in hardware verification.  The big ones at the moment are Specman, Vera, SystemVerilog, and SystemC.  Having experts in all of these languages makes it interesting when we discuss verification issues internally, and allows us to provide advice to clients who are trying to decide which verification language to use on future projects. My languages of choice on my last several projects have been Specman and SystemC.  In preparation for future projects I decided to mix things up a little and ramp up on Vera. 

Continue reading "A SpecManiac's Take on Vera" »


Problems Running Specman on Fedora Core 4

Here at Verilab we have FC3 and (coming soon) FC4 servers running most of the major EDA simulation and verification tools.  Unfortunately for me they are all located in the UK which means a lot of variation in the performance I get over my VNC session.  I mentioned previously we are working on developing a Specman testbench for the Opencores.org Ethernet core as a training mechanism for some of our guys who are learning Specman.  To make it easier to do the work from Austin I've installed FC4 under VMware and over the last several days have been installing the relevant EDA tools so I can access everything locally.  Unfortunately, I immediately began having problems with the Specman GUI.  The "Modules", "Coverage", and "Sys" buttons weren't operational - I would get a message saying "Connecting to GUI...".  After much pulling of hair and gnashing of teeth our systems administrator and I were able to come up with a solution.  Turns out that I had SELinux enabled.  Once I turned it off the Specview GUI worked just fine.  Important safety tip!


Creating a Specman Testbench for the Opencores.org Ethernet Core

Starting this week one of my fellow Verilaber's (is that a word?) from Scotland is in Austin.  The goal is for us to develop a testbench for the Opencores.org Ethernet module using Specman over the next two weeks.  We're going to use the opportunity to allow me to pass along some of my knowledge of the e language and best practices for e testbench development.  The guy I'm working with is no stranger to verification himself. He is a verification expert with years of experience using Vera and (more recently) SystemVerilog.  This is one of the cool things about working at Verilab -- we've got people who have expertise in a wide range of areas.  The best part of working with someone who is learning a new language, especially someone who is an expert in other languages, is that it makes you question some of the things you've been doing by rote without ever truly stopping to wonder why. My personal goal for the week is to use the opportunity to enhance my own testbench development skills and perhaps end up with some verification IP we can use for future training purposes - not just for e but SystemVerilog - especially the assertions portion for starters.

Today we spent time working on the directory structure, patching the Ethernet environment from Opencores.org to remove dependencies on Xilinx and Artisan libraries, and creating shells for the eVCs we'll be developing along the way (Wishbone, MII, and one for the entire Ethernet environment as a whole).  We also drew some block diagrams of the system to make sure we were both on the same page regarding the direction of the testbench.  Tomorrow we'll hopefully be able to continue creating the shells for the eVCs and if we're lucky resolve some of those pesky startup issues that occur on every project.  We've got an extra issue in that I've been trying to get Cadence Incisive and Specman installed under Fedora Core 4.  They mostly work but I'm having some GUI issues with Specview that I haven't been able to resolve ("Connecting to gui...").