ENUM Types for StateMachines

Hello Bryan,

An enumeration without a type declaration defaults to int - which has an initial value of 0. If you declare an enumeration using a 4-state type (integer, logic, reg), then the default value will be 'X'.

There were changes made between the Accellera 3.1a spec and the IEEE1800 spec for initialization of enumerations, but I could not find specific details in the IEEE1800 spec, but I believe default initialization to the left-most value is not part of the spec. I'm pretty sure the changes were made based on issues like the one you raised in your posting. Enumerations in the testbench would not be a problem, but for synthesis, the default type should match the data type default initial values. I would suggest that you use 4-state logic in your design - and 2-state logic in the testbench.

The way the IUS simulator has implemented enumerations is that the initial value of an enumeration variable is the default value of that data type. For example:

typedef enum {RED=1, GREEN=2, BLUE=3} colors_e; // defaults to 32'bit int per the IEEE spec
typedef enum logic [2:0] { RESET=0, IDLE=1, COMPUTE=2, STORE=3, ... } state_e; // 3-bit 4-state enumeration type

colors_e my_color; // this will initialize to 32'd0
colors_e my_other_color = my_other_color.first(); // this will initialize to RED
state_e current, next; // these variables will initialize to 3'hx

I hope this helps!

Kathleen Meade

Originally posted in cdnusers.org by kameade

Thank you. I am currently using the "logic" approach and will stay with that based on your comments. I value the verification over any ease in switching back and forth between one-hot and encouded statemachines. Though it would be nice to get both.

Originally posted in cdnusers.org by bryan

Suggestion of using "loigic" is very sensible, I like that. Also make sure you use proper Design Checking tool a.k.a Lint tools such as HAL (from CDN), Spyglass, Leda etc. They can verify this kind of stuff without any simulation, quite effective indeed.

Another highly valuable tip is to add a functional coverage point like:

  c_rst_in_middle : assert property (@(posedge clk) !rst_n ##[1:$] rst_n ##1 !rst_n |-> my_state == IDLE);

Idea is to see a reset appearing in the middle of simulation run (after few cycles/xactions) and guarantee that the design indeed got reset.

HTH
Ajeetha, CVC
www.noveldv.com

Originally posted in cdnusers.org by ajeetha

I (we) have been using (for years) tools like you describe to identify "reset" issues but they are not full proof. Plus it is nice to have more than one method to verify something. Nothing like a backup. Good Idea about the using the assertion. We're not using imbedded SVA assertions (simulation control reasons) but I am sure I can construct something similar using OVL. As you say the idea is to just cover the fact that Reset is activated and that causes a transistion into the RESET state.

Originally posted in cdnusers.org by bryan

That's interesting. Is it because of too much warnings that these tools throw up? Anyway as you said, "a backup is always good" so I would put Lint as a backup option as well :-) If you care to, can you elaborate on the "sim control reasons"? As you maybe aware, I've co-authored 2 books on Assertions and have seen few ways to handle this: 1. Ifdef - compile time control 2. $test$plusargs - run time, perf issue 3. Using TCL - becomes tool dependent somewhat and having TCL enabled in itself is a perf killer 4. $assertoff/on - run time control, LRM compliant - again not so great on perf though. But what is more interesting to me is you are saying:
Do you really expect to see a big perf difference among OVL vs. SVA/PSL? Has anyone done such a comparison? I would imagine that tools like NC who have been supporting assertions for close to 4+ years must have optimized their engines and hence you won't see much difference. Or was your concern more on just the language (and perhaps license) than performance? Regards Ajeetha, CVC www.noveldv.com

Originally posted in cdnusers.org by ajeetha

Yep. LInt and automatic formal tools are a staple.

It is not a performance difference is it the ability of the TB to control determine how to respond to the assertion. Turn them on/off dynamically during the test, turn them in to functional coverage items for some TCs and as assertions for others or just to have them push messages in to the simulation log file. It absolutely has nothing to do with performance and its all about what we can do with them in our native HVL language. We measure our performance slow down due to OVL. We saw about a 7% slow down. We have never done any comparison with SVA/PSL versus OVL (RTL). Now that OVL has SVA/PSL implementations perhaps we could but right now our concern is more about using them wisely. Any loss of simulation performance can be fixed with a faster machine. :-)

Originally posted in cdnusers.org by bryan