Introduction
About the Tutorial
This part of the website is dedicated for those who are just taking their first steps with Specman. The first chapter is a sort of an "executive summary", discribing Specman's basic working principles and discussing briefly its main pros and cons. If you are currently going through the frustrating stage of choosing the most adequate verification tool for your team, this chapter might help you out. The second and third parts describe the main features and constructs of the e language, while the fourth chapter shows the structure of typical Specman testbench. These parts, corresponding, might be considered as the "physical" and "logical" aspects of working with Specman-e. Each "physical" element is used to implement a different "logical" part of the testbench, i.e., each of the language constructs is used for a different functional purpose.
This document is a "breathing" document and I keep updating it as I learn more about Specman in particular and verification in general. Almost all parts have been rewritten since I first published it, more than a year ago, and I will probably keep rewriting them until I retire, or until Cadence stops Specman support, whichever comes first. You are more than invited to send any comments, questions, tempting work offers or tempting personal offers to avidan_e@yahoo.com.
Naming Conventions for Tutorial Examples
User defined type names, struct names, unit names - all start with a capital letter.
User defined struct member names (fields, events, methods) - all start with lower case letter.
In both cases each of the parts of the name also starts with a capital letter.
HDL signals - all lower case, parts of the name are separated with underscores.
Non-user defined names (that is, those names that are part of the e language) - follow the naming conventions specified in the proposed e standard (eLRM)
These very simple rules are shown in the example below:
<' // type names start with a capital letter each part of a name starts with capital letter...therefore PacketSize and not Packetsize, Packet_size or anything else type PacketSize : [small, medium, big]; // unit and struct names start with a capital letter unit ChipEnv { // fields, events, methods (in one word - struct members) // start with lower case letter chipAddress : uint; event configDone; resetChip() is { // a reference to an HDL signal name, // all lower case, parts separated by underscores 'sys_reset' = 0; }; // another user defined method endSim() is { // a method that is a part of the e language - follows // the e proposed standard naming conventions // (names are all lower case, // parts of a name are separated by underscores) dut_error("simulation ended without error, that's strange"); }; }; '>
The main idea behind this naming convention is to help the reader distinguish between the types, structs and fields that were defined by me ("user defined") and those that are parts of the e language. This is an extremely convenient naming convention for newbies, who are not familiar with the names that are parts of the language, but I use it also in real life...
Next-At a Quick Glance
