| Concurrent Board Process |
This chapter provides a brief discussion of the Concurrent Board Process or CBP methodology, and how to implement this methodology using the userware that is provided.
In order to access the CBP userware in Design Architect, you need to add the cbp_da personality module to the list of personality modules to load into Design Architect:
% setenv DES_ARCH_PKGS_TO_LOAD `Mt_da cbp_da ...`
Please note that this section contains many extracts from the "Concurrent Board Process" white paper written by Randy Hartgrove of Mentor Graphics Corporation.
Overview The Concurrent Board Process, or CBP in short, is a design methodology that allows an Engineer (or a team of Engineers) to develop a schematic design, while a PCB Designer performs the board layout portion of the design. The CBP allows the Engineer(s) to create a root schematic for the design, get the design into a state that is worth handling to the PCB designer (not necessarily finished, but enough to begin working on), and then allow both the Engineer(s) and the PCB designer to continue working concurrently. This design methodology uses a single schematic design, with multiple design viewpoints to manage the design in progress. Because the design is developed concurrently by the Engineer(s) and the PCB designer, a process known as "synchronise" must be used to bring the different viewpoints of the design together into a single view of the design.
Viewpoints CreationThe first step of the CBP is to create the two design viewpoints which are required for the specified component (design): the Engineering viewpoint (default) and the PCB Design viewpoint (pcb_design_vpt). These viewpoints contain back annotation objects in which all design annotations will be stored.
On one side, the Engineering viewpoint contains, as well as its own back annotation object, the PCB Design back annotation object connected in read-only mode, without locking the PCB Designer out of the PCB Design back annotation object. This is the key to allowing true concurrent design effort. In addition, the Engineering viewpoint latches the PCB Design back annotation object so that any modifications made by the PCB Designer are not randomly loaded into the Engineer's view of the design. The Engineer(s) must make a conscious decision to update the latch on the PCB Design back annotation object so that the latest PCB changes are seen. This is accomplished by executing the "update" option of the Board Process utility. On the other side, the PCB Design viewpoint does a latch on the schematic sheets so that the design remains stable for the PCB Designer. Without latching the schematic sheets, every time the Engineer(s) saved a change to the schematic, the PCB Designer's view of the design would be different and would cause the whole CBP to become unstable.
An example of viewpoint reference file is:
# Viewpoint References for $OLIVIER/demos/cbp/pcb_design_vpt
BACK ANNOTATION MANAGERS
$OLIVIER/demos/cbp/pcb_design_vpt[3]
DESIGN OBJECTS
$OLIVIER/demos/cbp
$OLIVIER/demos/cbp/part[4] [latched]
$OLIVIER/demos/cbp/schematic[61] [latched]
$OLIVIER/demos/cbp/schematic/sheet1[30] [latched]
$OLIVIER/demos/cbp/schematic/sheet2[2] [latched]
$OLIVIER/demos/cbp/schematic/sheet3[1] [latched]
$OLIVIER/demos/cbp/memory
$OLIVIER/demos/cbp/memory/part[1] [latched]
$OLIVIER/demos/cbp/memory/memory[1] [latched]
$OLIVIER/demos/cbp/memory/schematic[8] [latched]
$OLIVIER/demos/cbp/memory/schematic/sheet1[8] [latched]
$OLIVIER/demos/cbp/analog
$OLIVIER/demos/cbp/analog/part[2] [latched]
$OLIVIER/demos/cbp/analog/analog[2] [latched]
$OLIVIER/demos/cbp/analog/schematic[19] [latched]
$OLIVIER/demos/cbp/analog/schematic/sheet1[19] [latched]
Design FlowWhen the Engineer(s) begin editing the schematic design, they should always work in the "context" of their design viewpoint. The Engineer(s) should always use the "Set Viewpoint" command in Design Architect prior to using the "Open Sheet" command. The "Set Viewpoint" command will insure that the Engineer(s) are always editing in the context of the design viewpoint.
By editing in the design context, the Engineer(s) can be sure that any property changes will be directed to the Engineering back annotation object. In this way any changes made to the design can be managed more effectively. If property changes are made to the source schematic sheet, then those annotations will not be manageable through the CBP methodology.
When the Engineer(s) has made a first pass at creating the design, and is ready to hand it over to the PCB Designer to begin board layout, the design must be synchronised to forward any PCB specific annotations from the Engineering back annotation object to the PCB Design back annotation object. This step is necessary for two reasons:
1- The Engineer(s) have been making changes to the design while editing the design in the context of the Engineering viewpoint. All annotations, whatever they are, were saved in the Engineering back annotation object.
2- The PCB Design viewpoint has only the PCB Design back annotation object connected. Any annotations not specifically saved in this back annotation object will not be visible to the PCB designer. At the end of the first design iteration, when the Engineer(s) are ready to hand work over to the PCB Designer, there may be some PCB specific annotations saved in the Engineering back annotation object that must be moved to the PCB design back annotation object in order to be recognised by the PCB Designer.
Now that the Engineering changes have been forward annotated to the PCB designer, and both the PCB Design viewpoint and the Engineering viewpoint are up-to-date, it is time to begin the concurrent design work.
At this time modifications can be made to the Engineering view of the design, allowing simulation and analysis to affect refinement of the design. Some of these changes could be changing technology of logic components (i.e. form LS to F) or grouping components together to insure proper performance.
At the same time changes may also be made to the layout view of the design, allowing components to be packaged, assigned reference designators and placed onto the PCB as would normally be done. However the PCB designer must be sure to always back annotate design changes, in order for the CBP methodology to work properly, and the Engineer(s) must update the latch on the PCB Design back annotation object to see the PCB Designer's annotations. Once again when editing in the design context, the Engineer(s) will save any property changes to the Engineering back annotation object which will not be visible to the PCB designer until the next synchronise step is completed as was done previously.
After the Engineering work is complete, the design must be completed by the PCB Designer. If a CBP methodology has been followed, the time between Engineering work being complete, and the PCB Design being complete will be shortened. However, there will be some time required to allow one more design iteration by the PCB designer to insure that no changes have been made by the Engineer(s) that will affect the PCB Design. The recommended best practice is to run the synchronize step one last time after Engineering has completed their work. After synchronise is complete, run Package once more on the design to insure that no PART_NO and REF properties have been changed. Invoke Layout and FabLink as usual to complete the PCB design and do a final back annotation.
Reconcile UtilityThe "Reconcile" utility is used to merge the back annotations from the PCB Design back annotation object and the Design Engineer back annotation object. It uses a configuration file that defines which properties should be reconciled, and whose property values wins in case of a conflit. The default configuration name is the destination back annotation name with a .reconcile_config extension. This way there can be a pcb_design_vpt.reconcile_config and a default.reconcile_config configuration files. The "Reconcile" utility will look for the configuration files in the following directories:
Please refer to the "Design Viewpoint Editor User's and Reference Manual" for more information on the "Reconcile" utility.
An example of reconcile_log file is:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Run of Reconcile on: Wed Sep 24 12:46:56 1997 User: olivier Reconcile /user/olivier/demos/cbp -context /user/olivier/demos/cbp/pcb_design_vpt -source /user/olivier/demos/cbp/default -destination /user/olivier/demos/cbp/pcb_design_vpt -config pcb_design_vpt.reconcile_config -preview =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= // Note: Using configuration file "../user/idea_B.4-F.hpu/shared/etc/cust/pcb_design_vpt.reconcile_config" // Note : Preview file is located at "../user/olivier/demos/cbp/preview_log". =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Run of Reconcile on: Wed Sep 24 16:50:03 1997 User: olivier Reconcile /user/olivier/demos/cbp -context /user/olivier/demos/cbp/pcb_design_vpt -source /user/olivier/demos/cbp/default -destination /user/olivier/demos/cbp/pcb_design_vpt -config pcb_design_vpt.reconcile_config -preview =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= // Note: Using configuration file "../user/idea_B.4-F.hpu/shared/etc/cust/pcb_design_vpt.reconcile_config" // Note : Preview file is located at "../user/olivier/demos/cbp/preview_log".
with the preview_log file:
// Note : Property "ref" with value "IC2" on "../I$476" would be moved to the destination. // Note : Property "pin_no" with value "4" on "../I$476/1A1" would be moved to the destination. // Note : Property "pin_no" with value "2" on "../I$476/1A2" would be moved to the destination. // Note : Property "pin_no" with value "16" on "../I$476/1Y1" would be moved to the destination. // Note : Property "pin_no" with value "18" on "../I$476/1Y2" would be moved to the destination.
and pcb_design_vpt.reconcile_config file:
#!RECONCILE 1.0
# Default Reconcile configuration file for engr_ba to pcb_design_vpt
INST SOURCE-WARN REF PART_NO GEOM TECH POWER_NETS POW_MIN;
INST SOURCE-WARN POW_TYP;
INST SOURCE-WARN POW_MAX POWER_PINS SWAPPING COMP_HEIGHT VALUE;
INST SOURCE-WARN SPICEPAR TOLER TRIM LASER SURFACE INK_ID R_LEN;
INST SOURCE-WARN R_WIDTH R_SHAPE R_HAT_LEN R_HAT_WIDTH R_MIN_DIM;
INST SOURCE-WARN PLACEMENT_REGION INSTPAR BOM_DESC;
INST SOURCE-WARN COMPONENT_TYPE PCB_SIZE GATE_CLASS;
INST SOURCE-WARN DUAL_FOOTPRINT;
INST SOURCE COMP PCB_INST SHARED;
INST DESTINATION-WARN BRD_LOC DEC_CAP;
INST DESTINATION REFLOC JUNCTION_MAX_T POW_DERATING POW_DEL_MAX;
INST DESTINATION POW_DEL_MIN PINS_OUT MFG THERM_JC THERM_R;
INST DESTINATION THERM_COND SPEC_HEAT MASS_DENSITY SURFACE_AREA;
INST DESTINATION PCB_GROUP PCB_PIN_LOC PCB_PIN_PAD;
PIN SOURCE-WARN PIN_SWAP CONN_ORDER PIN_GROUP MAX_STUB MIN_STUB;
PIN SOURCE-WARN PIN_TP_REQ;
PIN SOURCE PCB_PIN PINTYPE;
PIN DESTINATION-WARN PIN_NO PIN_ORDER;
PIN DESTINATION ADDED_NET
PCB_PIN_LOC
PCB_PIN_PAD
PCB_BA_NET;
NET SOURCE-WARN NET_ORDER NET_LENGTH NET_PRIO NET_TYPE RESTRICT;
NET SOURCE-WARN TERMINATOR ELEC_CLASS BALANCE_PAIN;
NET SOURCE-WARN TRACE_SHIELDING MATCH_GROUP NET_TP_REQ;
NET SOURCE-WARN NET_TP_MIN_CLEARANCE;
NET SOURCE PCB_NET;
NET DESTINATION-WARN SOURCE
PCB_GROUP
PCB_BA_NAME;
Pitfalls When developing a design using the CBP methodology, there are some potential pitfalls that should be avoided.
Properties can have a status of fixed, protected or variable as defined on the symbol. Fixed and protected properties cannot be changed on the schematic but currently those can be changed by the PCB designer by editing the property value in either Package or Layout. Changes to fixed or protected properties may then be back annotated to the PCB design back annotation object, and will be visible to the Engineering viewpoint even though those property values are invalid. In order to control whether fixed or protected properties can be back annotated or not, an option called ANNOTATE_FIXED_PROP ON|OFF can be set in the Package configuration file to prevent the back annotation of these changes.
Properties assigned to nets are back annotated based on the net handles or net names. If the Engineer(s) changes a net name, which must be done on the source schematic, then all annotations assigned to the previous net name will be deleted from the back annotation object resulting in a loss of annotations.
Property annotations assigned to instances through a design viewpoint are assigned to the instance handles. If an instance handle changes, or if an instance is removed from the design, then once again all annotations assigned to that instance are also removed from the design. This situation can occur when the Engineer(s) delete a schematic symbol from a schematic sheet. As the instance is removed, so is its handle and all annotations assigned to that instance. When changing logic symbols it is important to use the "Replace" command in Design Architect. The "Replace" command allows the Engineer(s) to replace one symbol with another one while preserving the instance handle, and preserving any annotations assigned to that symbol. The same applies when updating a schematic symbol with a more recent version of that same symbol where the "Update" command should be used.
List of functions:
webmaster@eda.com.au