ENUM Types for StateMachines > Forums

Forums

Subject: ENUM Types for StateMachines

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

bryan
Posts: 25
Online: User is Offline

3/17/2007 11:22 AM
If I understand ENUM types correctly any variable declared of that type will be automatically initialized to the left most value. When using these for SM logic this is concerning because you would be vulnerable to not verifying that you have reset implemented correctly. Would the answer to this delima be to declare a "dummy" state in the list which is not declared during synthesis (use synthesis_off/on) or should the enum be of type logic which then would allow values of X for the item in the ENUM list? Or Something else? Does either approach make it easier to use Synthesis tool techniques for switch SM encoding between One-Hot and Encoded? The idea would here would be to avoid changing the RTL.

Regards, Bryan

kameade
Posts: 13
Online: User is Offline

3/17/2007 2:11 PM
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 ΐ: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

bryan
Posts: 25
Online: User is Offline

3/18/2007 5:35 AM
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.

Regards, Bryan

ajeetha
Posts: 97
Online: User is Offline

3/18/2007 7:22 AM
Posted By bryan on 3/17/2007 11:22 AM If I understand ENUM types correctly any variable declared of that type will be automatically initialized to the left most value. When using these for SM logic this is concerning because you would be vulnerable to not verifying that you have reset implemented correctly. . 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 ##Ώ:$] 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

bryan
Posts: 25
Online: User is Offline

3/18/2007 8:19 AM
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.

Regards, Bryan

ajeetha
Posts: 97
Online: User is Offline

3/18/2007 9:43 AM
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. 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 :-) Posted By bryan on 3/18/2007 8:19 AM Good Idea about the using the assertion. We're not using imbedded SVA assertions (simulation control reasons) 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: but I am sure I can construct something similar using OVL. 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

bryan
Posts: 25
Online: User is Offline

3/18/2007 12:50 PM
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. :-)

Regards, Bryan

Posting to forums is available to community members only.
Login or Register