State Machine Editor (fizzim?) Design Specifications

The object is to provide a comfortable “bubbles and arrows” design environment, while decoupling this as much as possible from the HDL code implementation.  The output will be some sort of database (preferably ascii and preferably with a parser module available in perl).  This database will contain both functional information of use to the backend processor as well as graphical information of value to the gui.

A backend processor will read the database and create verilog (or vhdl, or C, or whatever) code.  We will supply an intial simple backend in perl.  Hopefully others will contribute to the backend project.  We should also look at interfacing to fsm_perl, if it still exists.

From the gui’s perspective, there are only two types of objects – states and transitions.  Each of these can have attributes assigned.  Some attributes are “standard”, but you can add your own.  From the point of view of the gui, the only difference is that the standard ones are given to you by default to save typing, and cannot be removed.  The gui has little or no understanding of what the attributes mean.

Attributes can also be assigned to the state machine itself.  These are global attributes.

Attributes are created and managed on a central tab (probably left-click in an open area, select properties, then select an attributes tab).  This allows defaults to be set and so forth.  There are three attribute tabs, one for global attributes, one for state attributes, and one for transition attributes.  Each attribute has the following fields:

1. Name.  This will be uneditable for standard attributes.
2. Default value.  This is a string.  The gui has no idea what it means.
3. Visibility.  Select “always”, “never” or “non-default”.  This sets the default visiblity for the attribute, but this can be overridden on a per-object basis by editing the visibility field on the attribute page of the object itself.
4. Color (present but not implemented initially).
5. Type?  Not user settable?  Allows inputs/outputs to be easily identified.

In addition, each attributes table (meaning each tab) can be made visible and placed on the page for those who like everything shown.

Any attribute that is defined will show up on the attributes tab of all objects of the appropriate type.  Any user-defined attributes MUST be created in the appropriate attributes definition tab before it will show up on the objects. 

Issue: How/when are attribute values  placed on page if centrally defined?  If user adds one with visibility on, does it auto’ly pop up on all related objects?

Initial location will be on/near the object.  The user can then move it and it stays put unless moved again.  It would be nice if this location information were relative to the object so that it moves with the object.  In the initial implementation, the gui won’t spend a lot of effort trying to find a “nice” location.  Just slap it down and let the user move it.

Each attribute should have a “visibility” property.  Options are on/off/default.  Default value comes from the global attributes page described above.

Standard global Attributes:

1. Backend command. This would allow the user to place this information on the page so that the backend command and all it’s options are shown.  In the future, this will be used to actually launch the backend.
2. Endcoding.  Standard values would be “encoded”, “one-hot”.  User should definitely be able to create new ones.  As an enhancement, it would be nice to be able to call the backend with a –guiinfo option and get back all the various special values.  See enhancements.
3. Top-of-file command.  The backend should put this code (just a string to the gui) ahead of the module statement.  Used for setting `defines or doing `include.
4. Top-of-module command. The backend should put this code (just a string to the gui) after the module statement and input/output/wire/reg declarations, but before the actual code.
5. Bottom-of-file command.  The backend should put this code (just a string to the gui) after of the endmodule statement.  Not sure what you would use this for, but it seems handy.
6. Inputs.  These should be created on a special tab.  They don’t create any attributes on any objects (just info to help the backend).
7. Outputs.  These should be created on a special tab.  Each output will cause an output attribute with that name to be created for each state and each transition.  Visibility is can be set as described earlier, so (for example), if the visibility is defined as non-default, nothing would show up on any state or transition when the output is created.

Standard state attributes:

1. State name

This will just be a string (in the “value” field).  It will be up to the backend tool to map this to a value however it wants. 

2. Output values (one per output created in the global outputs tab):

Just a string to the gui.  For reg’d outputs, a constant.  For mealy outputs, this could be an equation.

3. State vector.  This is for users who want to force the backend processor to assign a particular value to a state.  If undefined, the backend processor is free to choose the assignments.  The gui will treat this as a string.  It will be up to the backend processor to recognize binary, hex.  Alternatively, we could put “auto” in this field as the default.  Question: Once defined, how do you un-define it?  Edit to blank? Type in “auto”?

Standard transition attributes:

1. Transition equation. 

This is just a string to the gui.

2. Output values.  Note that an output value set on a transition is a mealy output by definition.  “value” field could be a constant or an equation.
3. Priority.  This tells the backend processor what order to put the transitions in.  This allows the transition equations to be simpler to read when they have an inherent priority.
4. Grey code required.  Tells the backend processor that this transition should be grey coded.  It’s up to the backend processor to figure out how.

Users may define their own attributes.  These could be specific to a particular backend processor, or this feature could be used to add comments.

In addition to setting properties and attributes, there are some gui operations.

Operations.

1. Add a new state.

Just pops up a new state bubble where you click.  You can then select it, move it, resize it, and edit its attributes.

2. Add a state transition

State transition snaps a straight line between the selected states, whose anchor points can then be moved using edit object. 

3. Add a loopback transition

Just puts up loopback arc.  Loopback should be the default behavior if no transition equations are true, so this can be just for looks.  But it should also be possible to put an equation on the loopback arc and actually have the default behavior be a normal transition arc with an equation of “1”.  To make this work, you’d have to give the loopback arc a higher priority than the new default arc.  Not sure how hard this will be to implement in the backend processor. 

4. Edit object

Allows you to grow/shrink bubbles, and move anchor points on transition arrows.

5. Move a state.

The ends of the arcs stay connected.  You can edit the arc points to pretty them up. 

Issue:  What happens to previously edited transition arc points when one of the states is moved?

Issues:

1. Should the user specify in the gui what the inputs and ouputs are?  Does this then automatically create attrbutes of that name on the states?  Does the gui have to know if outputs are registered or not?  Does the backend processor have to know?  Are outputs just “user defined attributes”?
2. (related to 1 above)  How are outputs defined?  If the fields are only “name”, “value”, etc we need something to indicate this is of type output.  Should “type” be a field?  Then “name” would be greyed out for things like state name, priority, etc?

Enhancements

1. Add multiple pages and page connectors.  The DB format should be set up for this from the beginning.
2. Have the gui find a nice initial location for attributes.
3. Allow user to call the backend processor from the gui.
4. Be able to call the backend with –guiinfo option and get back all the special attributes and values supported by that backend.  Perhaps the –guiinfo option just causes the backend to dump a “db” type file?