One of my favorite quotes about SW programming is the following by Edsger Dijkstra: "If debugging is the process of removing software bugs, then programming must be the process of putting them in." Yes, we all insert bugs while we write code. And a significant part of the verification development time is spent on debugging. You might be tempted to think that most debugging time is spent on detecting errors like memory corruption, race condition, etc. However, most of our debugging time is usually spent on the most "stupid" mistakes. This blog is about helping you detect one kind of these mistakes just after you write your code.
Let's take the following example: You have some design in System Verilog that includes the following:
typedef enum {NOP, READ, WRITE, IDLE, DONE } read_write_t;
read_write_t op;
Your e test drives op and compares the result, so you declare the following in your e test:
type read_write_t : [NOP,WRITE,READ, IDLE, DONE];
unit top {
op_p : inout simple_port of read_write_t is instance;
keep bind(op_p, external);
keep op_p.hdl_path() == "~/top/op";
….
};
Now let's see how sharp-eyed you are. Have you noticed that the enumerator is defined differently? READ and WRITE position is switched in the e code.
SystemVerilog code:
typedef enum {NOP, READ, WRITE, IDLE, DONE } read_write_t;
e code:
type read_write_t : [NOP,WRITE,READ, IDLE, DONE];
Yes, that's the way the cookie crumbles…. If you are lucky, then things will not work properly the first time you try to run the test, and if you are a good debugger you will most likely find out why and fix it immediately. In the worst case, everything will work fine for now and something will not work properly only two weeks (or months…) from now when someone changes something in the test or in the design. Then, this error might cost you few hours of debugging….
For these kind of errors, a new command is introduced in Specman of Xcelium 17.04: set e2hdl checks. This command checks the compatibility of enumeration types in e and hdl. The check is done for each simple port of e enumeration type. You just need to remember to issue it before the elaboration.
So in our case, after we set this command and run the test, we get the following error (it is Error by default, you can change it to Warning):
*** Error - The external port 'top.op' of enum element type
'read_write_t' is bound to hdl object 'top.op' of type name 'read_write_t'. The
2th item 'WRITE' does not match literal 'READ'.
By default, the command is quite strict and it expects the name of the type in e to be identical to the name of the type in hdl. If you need more flexibility, you have a few options to allow different names for specific enum or even to ignore specific enum(s) at all. You can read about the various options in cdnshelp. In general, it is recommended to have this command issued by default to easily detect future errors.
One point worth mentioning is that to ensure that your test has fields that are identical to the fields in hdl, you can always use the mltypemap tool that can take a file in hdl and generate its matching file in e. You can read more about it in cdnshelp.
In Specman of Xcelium 17.04 we provided you with the ability to detect this error. In a future version we plan to totally eliminate the possibility of having this error. We plan to support the ability to point form your e code to the enumerator type in the hdl, so that you do not even need to define it in your e test. Check the What's New section in the next Xcelium versions…
Orit Kirshenberg
Specman team