The flow for efficiently and correctly designing a package substrate layout is a complex task. Many teams define steps to be followed by designers to make sure that rules and requirements are adhered to during the process.

To simplify this process, the Cadence® Allegro® layout tools offer the Design Workflow tool. This interface gives you the ability to define your own (hierarchical) design flow. As many different flows as you wish can be defined for the different engineers, teams, or design styles in play for your company.

Above, we see the basic workflow for IC Packaging design that is provided to you with the tool install. We’ll use it for our discussion today.

Workflows are completely optional. They are meant to simplify your life by bringing documentation and processes you already define today directly into the tool for reference whenever you need them. All that you need to do this, is some very basic understanding of the XML format and syntax and your favorite text editor.

Defining a Workflow with XML

XML is a standard format for defining information used in countless places. For this reason, it was selected as the mechanism for you to define your workflows.

The syntax is simple, as shown below. For simplicity, you may want to begin your work referencing the default workflow in the install. This can be found in the share/pcb/text/workflows folder. Choose any of these as your starting point.

When you’re done, just copy your new workflow XML file to one of the folders in your WORKFLOWPATH. If you want your workflow to be available to all your team members, place it at the site level referenced by the entire team.

Above, you’ll note there are only a few entries. A workflow tag starts a related grouping of actions, like Setup. Inside of this, you have a collection of groups, which is another level in the hierarchy, and tasks.

Tasks are your major entries. These are the commands and operations to be run by the user. Each gets a name, which is displayed as an HTML link in the workflow that can be clicked to run a command. The command here can be anything. It could be a basic command, such as die text in to run the Die Text-In Wizard. It can also be a sequence of commands that are run in order. It can be a script that is run or a macro. It can even be a SKILL function or more than one. The contents of a task are up to you to define based on how your team operates.

Our recommendation is to group your commands into workflows by design stages and to sort the workflows in the order they are intended to be run. Inside the flow, the tasks and groups should be similarly ordered. The result is a workflow that resembles the table of contents in a user manual or the steps in your favorite recipe.

Workflow Commands

There are three primary commands to interact with the Workflow widget’s display. You can use these interactively from the command line, or you can embed them into your scripts and SKILL code to automate the update of the flow items.

The commands are:

1. set_checked_workflow <Workflow Item> <true/false>

   Use this command to define a checkbox for this step and whether it is checked (usually to indicate that the action is fully complete) or not. true indicates checked, while false indicates unchecked. False is the default if no status value is provided.

   In the example above, the Netlist step has been checked with this command.

2. set_enable_workflow <Workflow Item> <true/false>

   Use this command to enable or disable a given item. If disabled, the item will show as grayed out and will not be selectable for use. Here, true indicates enabled, false is disabled, with false being the default value.

   In the example above, the Wire Set-Up step has been disabled with this command.

3. set_executed_workflow <Workflow Item> <true/false>

   Use this command to indicate whether this step in the flow has been run yet or not. Executed normally indicates that the command has been run. It doesn’t mean that the command is complete yet, though. A good example is a manual placement. You may have run this and placed five resistors, but if there are still 20 in the queue, it’s not complete. true indicates the command’s been executed, and false resets this status. The default is false.

   In the example above, all steps are currently unexecuted.

The commands can be used in many ways. You may integrate them directly into the flows, such as with the executed and checked items, by linking the task in the flow to running a script to execute a set of steps. If the steps only need be run once per design, then the script may end with a set_checked_workflow line that marks the flow item as complete. Embedding the status update directly inside the script removes a manual step from the user’s task list and reduces the likelihood of forgetting whether something has been done or not.

There is also the showhide_workflow command. This takes no arguments and just toggles whether the workflow panel is visible in the user interface, in case you only want to display it at certain times. This is equivalent to the View – Windows – Design Workflow command.

Using Workflows for Design Review

One great thing about using the Design Workflow inside of the tool instead of a standalone document is that the status of things can be maintained with the database.

Check the status of the design at any time. If the project is being worked on by multiple engineers, know what your peer completed before last saving the design. And, when it comes time for a design review, the flow gives you a quick snapshot of everything that has been done, and what is still pending completion.

However you leverage workflows, the one-time investment in defining them will certainly repay you many times over as you go through every new project. Try them out, and let us know what you think!