Darren Galpin, senior staff engineer at Infineon, recently became chair of the IEEE P1647 working group for e language standardization. In this guest blog, he describes what’s coming up for the 2010 revision of the verification language, and calls on e users to participate.
Trying to standardize a language is like trying to hit a moving target. You take a snapshot of where the language is, but by the time you get to the end of the standards process, things have moved on. The second revision of the e language was started at the tail end of 2006, and was published at the end of 2008. During that time the e language has moved on and new features have been added, so there is a need for a new revision which captures these features. There are also a couple of items that escaped the earlier versions and need to be included in the standard.
So what are we planning for the expected P1647-2010 revision?
Define-As-Computed Macros. This capability allows the definition of a new language construct using an action block to build the replacement code. It is included in the new revision requirements due to a direct user request.
- Interface Ports. The intent here is to support ports of standard transation level model (TLM) interfaces (originally from SystemC).
- Named Checks. Every check statement can be uniquely tagged with a name. This allows coverage to be collected automatically on checks, and coverage can be extended by constraints based on the name.
- Named Constraints. Every constraint can be uniquely tagged with a name, which allows individual constraints to be overridden by other higher-level constraints, or perhaps switched off if certain behavior is not desired.
- Parameterized Types. This allows template types in which you can define generic structs and units that are parameterized by type. They can be instantiated later by giving specific types as actual parameters.
- Real Data Type. This provides support for real numbers, which was added into Specman 6.0.
- Temporal Coverage. This is a generalization of the coverage group definition that allows data and temporal values to contribute equally to the implementation of a coverage model.
- Type Constraints. These restrict the declared type of a field to one of its kind, or as subtypes for a given context.
There might be more, and I would encourage anyone who thinks something is missing to join with our working group to help capture these features. The IEEE standardization process allows anyone with an interest to join in and contribute to the language and its development, and we encourage people to do so.
The language is now freely available to people who want to use it, and is free to develop in ways that users think desirable. Although developed by Verisity and subsequently Cadence, it has been donated and made open through the IEEE. The working group itself is driven by the users. I work for Infineon, and the vice-chair is Stylianos Diamantidis from the consultancy firm Globetech Solutions.
The people who are taking an interest in moving the language forward are also people who use it in their everyday jobs. I took on the responsibility of chairing IEEE P1467 because I use e every day, and I wish to ensure that the language continues in a way which is useful to us and allows us to continue to exploit its power and our past investments in time and effort. We have plenty of legacy code written in e, and especially in these financial times, we can't afford to simply rewrite it in another language. We need everyone to work together.
To join in, either go to www.ieee1647.org or e-mail the group’s reflector at email@example.com. We look forward to hearing from you.