Today, we’ll talk about something simple but still important. For all of you who write your own SKILL code commands to help your teams be more productive, this one’s for you.

Any time you are modifying the database, it is important that your end-user be able to undo the changes your command made if they notice an error. While still inside the command, you can implement the standard “oops” option in your mouse popup menu to undo the latest action. What happens after they finish the command, though? Most Cadence commands will place the command into the undo/redo command stacks, allowing you to undo (or redo) the actions recently performed.

This isn’t limited to Cadence commands, however. Did you know that you can make your SKILL commands undoable in the same way as any regular Cadence command? It’s possible, and today, we’ll cover how simple this powerful addition to your custom commands is.

The All-Important axlCmdRegister

The axlCmdRegister command is where the magic happens today. It’s the command used to register your command in the Allegro command table, meaning your user can run it from the command line by typing the appropriate command name. They can register it as a function key or alias if they want, even add it to the menu. Today, your call to this probably looks something like:

    axlCmdRegister("myCommand" 'myCommandMainFunction ?cmdType "interactive")

The line above registers your command, named myCommand, with the system. The main entry point is myCommandMainFunction, and its type is interactive (interactive commands will close the previous command before starting up; this is the type that should be used for any command which modifies the database).

The command register function has other arguments, as well. You can specify a function to be called when the command receives a DONE or CANCEL event (allowing you to do things like save any partial changes to the design or roll back anything that isn’t complete, yet). Beyond that, you can indicate whether you want the command to be undoable.

To do this, add the ?undo option and set it to true. Our command registration above would be amended to this:

    axlCmdRegister("myCommand" 'myCommandMainFunction ?cmdType "interactive" ?undo t)

That one extra argument is all it takes. By default, your commands will not be undo enabled. By setting this to true, you get that immediate benefit.

The Small Print 

This power comes with some responsibilities, however. Namely:

1. Commands that make large, sweeping changes to the database should not be undo enabled. Undo has a maximum amount of memory it may use before the undo stack gets cleared again. This is why some functions, like netlist import or auto placing all components, aren’t undoable.
2. Your command should use database transactions to wrap the changes being made to the database. This is true normally, but more so when making your command is undo-enabled. Transactions scope the changes being made to the design.
3. Commands which do not change the database (those normally with a command type of immediate) don’t need to be undo-enabled. Because they don’t change the database, there is nothing that needs to be remembered to undo this action. This applies to things like reports which extract and output data, but don’t make edits.

If your command meets these requirements, then you should be all set. Oh! But make sure your command name is representative of what actions you are performing. The command name is what will be listed in the undo pulldown and tooltip, so making sure the user knows what it represents will help them be more confident in what they are doing.

That's all there is to it. Add those simple six characters to one line of your file, and you are set!